0

I'm not particularly up on MVC as an architecture but isn't the Model just a duplication (except slower and buggier) of the database?

Given modern databases support stored queries, user definable functions etc. why treat them as an implementation detail?

Is it because programmers generally don't want to learn SQL/ Relational design? Or because there's a fundamental mismatch between relation and object models?

Broadly the database can present an API, why do it twice & more slowly.

Any McConnell like numbers to back up viewpoints would be greatly appreciated

Alistair Mackenzie
  • 119
  • 6

3 Answers3

3

The model is just that: an object-based model of the business domain. The database is also a model of the business domain, but in a different form, i.e. tables and relations. They complement each other; what one lacks, the other provides. It's not an inner platform; an inner platform would subvert the technology it is imitating. The Model does not do that; it depends on the features of a database; it doesn't replace those features.

Object-relational mapping is an imperfect solution to the impedance mismatch problem. But relational databases and their SQL language are a mature, well-established technology with many intrinsic benefits. Using an ORM allows you to have the best of both worlds; you can store objects in a mature, well-established technology, but still use SQL to solve set theory problems.

Further Reading
The "Vision" project, a cautionary tale about inner platform effect
(This is what an Inner Platform really looks like. You can skip the preamble and start reading at the subheading "Introducing Vision")

Community
  • 1
Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • I was reading about the Vision project yesterday, coincidentally. – Alistair Mackenzie Mar 13 '15 at 16:08
  • Same point - an RDBMS can present an API, not just tables/relations & views, hat exactly is the model adding? – Alistair Mackenzie Mar 13 '15 at 16:59
  • A [layer of abstraction](http://en.wikipedia.org/wiki/Abstraction_layer). – Robert Harvey Mar 13 '15 at 17:04
  • Yes, but what does it do that the dbs couldn't? – Alistair Mackenzie Mar 13 '15 at 17:16
  • It gives the database the ability to store and retrieve objects. Databases store data, so to get them to store objects, you have to convert the objects to data. And vice-versa. There are object-relational databases, but I've never worked with one, and I think you'll find that's true of most of your colleagues. One of the advantages of relational databases is that they are widely used and well-understood. – Robert Harvey Mar 13 '15 at 17:19
  • Robert, I think we're getting close - but a full answer from you would be appreciated. The Model layer translates between OO and Relational, only necessary because of mismatch in the first place! – Alistair Mackenzie Mar 13 '15 at 17:32
  • The mismatch only exists because object databases didn't become widely used. You're underestimating the benefits of adopting a widely-used, well-understood, stable technology, and adapting it to satisfactorily fulfill another purpose. – Robert Harvey Mar 13 '15 at 17:38
  • I accept your point about mature stable technologies and accept it's not an inner platform, but the model layer is a high price to pay both in performance and general bloat. – Alistair Mackenzie Mar 16 '15 at 10:42
  • Most of the performance hit occurs when you try to communicate across a network or run a query on the database server. The model layer doesn't actually contribute all that much to the performance delays. – Robert Harvey Mar 16 '15 at 14:55
  • Except the model layer defeats database optimisation, such as caching query plans and results in RAM. Not much you can do about network delays in either case, file/ mem caching of some sort usually needed. – Alistair Mackenzie Mar 20 '15 at 16:02
  • I suppose it depends on how well you've designed your model layer. Fundamentally, it just maps the results of SQL queries to objects, so the SQL queries themselves shouldn't be affected all that much, if at all. – Robert Harvey Mar 20 '15 at 18:46
1

You've got things the wrong way around.

The model is not a poor replica of the data base. No programmer cares about the data base. The data base exists only so that in a future invocation, we can easily reconstruct the same state of our business objects as before. Data bases are strictly a means to an end. They allow some processing and offer some tricks to speed up the inefficiency caused by mass storage access, but then they are also the sole cause of these inefficiency problems. If we could get by entirely without data bases and instead persist our business objects magically in the memory of tamed unicorns instead, we'd do it in a heartbeat.

The model isn't like that. The model supports all operations that we can do in our preferred programming language, which is why we chose it. The model is what we'd like to program. It is so central to the system that it is very important not to pollute it with concerns of other levels. This is why indices, table scans etc. should be kept out of the model, but also why combo boxes, HTTPRequests etc. should be kept out.

Not having a model would mean that the same code that deals with reading and writing widgets also deals with SQL INSERTs and connection parameters. That would be very bad, because thinking about two entirely different things all the time halves your efficiency as a developer. This s why it makes sense to separate those concerns and have layers dealing with the UI, with business logic, and with data storage. It leads to an increased amount of code, but since each of the resulting classes has a clearer focus of what it's supposed to do, general efficiency increases.

This result has been hard-won over several generations of programmers, and since it's non-obvious, every new generation has to be convinced anew that they will be better off not trying to do everything at once. But the majority of professionals will confirm that in this respect, having more and simpler classes is better, even if you end up with more code lines in total.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 1
    `If we could get by entirely without [table-based, relational] data bases and instead persist our business objects magically in the memory of tamed unicorns instead, we'd do it in a heartbeat` -- You can; it's called an "object database." There are good reasons why they are not widely used. – Robert Harvey Mar 13 '15 at 13:51
  • Thanks for your reply, you've asserted the standard viewpoint, but not defended it (in my view). "No programmer cares about databases", seems quite extreme. Any numbers for the greater efficiency claims? the SQL should all sit on the database is my main point - so the application code won't have any SQL in it. You can abstract away the connection details quite easily. – Alistair Mackenzie Mar 13 '15 at 13:54
  • Reasons for OO database failure in a nutshell are? – Alistair Mackenzie Mar 13 '15 at 13:58
  • @AlistairMackenzie: Sorry, thought you were the answerer. The reason OO databases never caught on is that table-based analysis of data is very useful in a business context, and it's hard to do that well in an object database. NoSQL suffers, to a certain degree, from the same problem. – Robert Harvey Mar 13 '15 at 13:58
  • @AlistairMackenzie: It sounds like you're an "all stored procedures, all the time" advocate. One of the benefits of SQL is that you can use it remotely across the network, not just on the database server itself. – Robert Harvey Mar 13 '15 at 14:02
  • Well SPs have the advantage that they're very fast (often cached in RAM) and can be made more secure than passing SQL strings about. But needs must sometimes! – Alistair Mackenzie Mar 13 '15 at 14:17
0

Only in the least complicated of applications might the model be a duplicate of the database and not necessarily even then.

Fundamentally that assumes a 1 to 1 mapping between the data presented to the consumer and the table structure of the database (be that relational or otherwise) and in reality that its seldom the case.

If we look at MVC the Model is the model for the view - even if this does just represent a single row from a single table the odds are that there are going to be lookups, fields that as presented to the consumer have a value but as stored in the database have an ID, your model may well then contain the display values as well as the actual data that is persisted.

Then we get into all kinds of interesting questions about validation - what and how and where.

Now take another step - note that I said "consumer" - what if that consumer is not an end user looking at a screen, what it its an Single Page App consuming an API. At this point from the point of view of the client facing app there is no database - but there is a model...

What this is giving us is a logic separation where we look at models that are appropriate to the context they're used in - one for the UI maybe a different one for use in business logic and then a the storage model which may well be relational and involve several tables. By treating them separately and ensuring we are comfortable mapping between them we end up with a great deal of flexibility in our overal structure (where the "system" may then fairly trivially span multiple applications).

Of course if all your doing is straight CRUD over tables of data then the relation between data model and view model may be quite close but if using a relational database there will still always be some mapping.

Murph
  • 7,813
  • 1
  • 28
  • 41