The model layer Vs database structure

I always find this hard to answer cause I do both. It depends on how much information I am given by a business manager in my place. Starting from the DB is a bad IMO. Usually I get a request like "we need the users to log on and complete this form" Which point i'm thinking directly about the database. The goal of such a project is to simply collect data. Once I know that I've got all the fields I need you can get tools to create your basic model to get you going, Illudium PU-36 Code Generator is a good example of this.

Very nicely put Paul, thanks.

I have learned from the MVC concepts but not tried to define my thinking inside another rework of the MVC concpets. MVC is as meaningless as it is meaningful. There are so many variations of this concept that in the end it is hard to tall if it is giving structure to the community or if it is constraining us to prove we are legit by giving yet one more way of doing MVC. You would think that being legit was proving you can express your methodology as an MVC. (I can do this to with COOP... but that doesn't make it legit.)

I tend to think more in controller, markup, processing, model and presentation layers. I don't feel the need to redefine things in an MVC package. I feel the need to have a functional system that can encapsulate, refactor and perform seperation of layered function.

With that said, the data is a seperate layer that is commonly handled in what is packaged inside a model. It is a data model function. If that helps you or another provide the data layer in a clean encapsulated layer to interface with the actual data store then that is good. If the need to follow some philosophy of what a model is abstracts reason rather than code then it is a bad thing. Bottom line is clean abstraction, encapsulation and layering through consistent interface and modulatirty are the goal. Wearing the uniform won't make us good soldiers or prove we are loyal in the long range. :)

What you have here is an implementation of the Data Mapper pattern. The benefit is that it gives you fine-grained control over how objects are persisted to the database. The cost is that it requires more manual coding over something like the Active Record pattern, which assumes a one-to-one mapping between database tables and objects. As such, much of this process can be automated, if you can live with the fact that your database is driving the structure of your domain model. In general, if you have a simple domain model, Active Record may be sufficient. I just think the single-minded focus on it (mainly from Rails) is causing problems because people now assume that it must be the "best" way to deal with the data layer.