How abstracted should MVC models be?

Question

I'm in the process of extending and improving a website that has quite a few structural problems. It looks very much like the developers before me had heard of MVC but didn't understand the ideas of abstraction or modularity. So the MVC "framework" is a) bespoke b) broken c) patched and d) there are several in use all at once. I intend to fix that.

This is not the first time I've re-built a site's framework, BTW, but it is the first time I've had to fix an MVC framework. However, I'm coming up against some missing holes in the MVC knowledge here on SO.

The first is how closely programmers seem to tie their SQL database with their models. This doesn't make sense to me: do programmers normally have the model looking after the data abstraction? (To me this is little better than putting SQL in raw PHP code.) Or is there a data access layer normally employed that "Does SQL"? I know from experience that the latter means the calling code doesn't have to worry about where the data is, or how to get it or how to write it: the API handles that.

But what about the Models? Are they intended to be re-usable amongst different pages? Should they care about just where the data is stored? Shouldn't they be more concerned with handling the logic between data-fetch and data-show (e.g. turning a contact's group ID into a displayable name)? And data-save and data-write (e.g. figuring out how to turn $_POST values into savable data)?

Maybe the MVC model really be DMVC - Data-Model-View-Controller.

Lastly, although this is from a PHP point-of-view, how well do these concepts translate to a JSP site?

Answer 1

You'll find more than one thread here about whether to start work from the database schema or the user interface. There's one place to look.

I can think of far more than one tool that takes a schema and builds your CRUD UI for you ("scaffolding") than vice versa. There's another place to look. (Poster-child: Ruby on Rails and its cognitive offspring).

When discussing ORM tools, there are too many times (but not all by any means) when the preferred acronym would be "ROM".

We have a lot of tools that encourage us in our evil propensity for "Ready, Fire, Aim". For management, it's the shortest line between "Proof of Concept" and "RC1".

Answer 2

But what about the Models? Are they intended to be re-usable amongst different pages?

Yes.

Should they care about just where the data is stored?

No. They need not know it. All this kinda information is necessary for persistence layer or data layer.

Shouldn't they be more concerned with handling the logic between data-fetch and data-show (e.g. turning a contact's group ID into a displayable name)?

No. They are just concerned about the business logic. Some usual application I have found the folks make the model dumb, just having attributes/properties and nothing else. The typical example in Java would be POJO, with getters/setters. We call them TOs (Transfer Objects), and use them everywhere, as a data holder. I am not really in the accord of this, IMO, there should be some methods, business related, which are appropriate and qualify to be in there. Don't make it so dumb. The new Entity Beans (EJB3) are the good example of this.

BTW, data show is the work of a presentation layer. In java JSP is the part of view technology.

And data-save and data-write (e.g. figuring out how to turn $_POST values into savable data)?

No. This is generally done in our controllers, most of the time using some utility classes.