>> GreenByte.info By Nick Tong (quiksilv) | Supported by: TalkWebSolutions.co.uk

The model layer Vs database structure

Posted At : 19 October 2007 08:36 | Posted By : quiksilv
Related Categories: Development

There have been a few discussions recently about the model and the database structure, and which one to start with. I thought I would throw my thoughts out and see what people think. To me the database structure is, as the name suggests, just about the database. When developing a system you should start with the model, rather than the database structure. Now to me, the model is where your back end business logic resides. Lets take a MVC application example.

Imaging that you have a user logging into your system. You have a request (form post) which is handled by your controller. The controller then makes a request to your model layer. Your model layer does the back-end logic some of which may be making calling to you database structure.

Taking a close look at the model layer.
Lets say you have a service layer. To pre validate the password your service layer makes a call to a utils.cfc to check that the password submitted contains a number. If it does it then the service calls your DAO which makes a call to your database and returns your query result. This result is then passed back to your service layer which then carrys out futher logic i.e. return an inValid login message, log a successful login, makes a call to a user object etc.

The point being that it's in your model layer* where your business logic goes, and it's why this is more important to start with this rather than your database structure.

Here is a diagram which I hope helps:

Model Layer

What is your take on it?

* Be it the 'M' in MVC or the service layer object.


 
Comments (9) | Print | Send | del.icio.us | Linking Blogs | Digg | 3953 Views
Comments
[Add Comment]
Neil Middleton's Gravatar Always start with the model after all that's the bit that supports the business requirements. Your DB is purely there to store stuff needed by everything else
# Posted By Neil Middleton | 19/10/07 11:15 | Report abusive comment
Andy J's Gravatar 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.
# Posted By Andy J | 19/10/07 11:43 | Report abusive comment
Paul Marcotte's Gravatar There are really two models that you need to consider when designing an application. A Domain model and an Application model. The Domain model represents objects like User, Product, Invoice and how they are related. A database eventually becomes the persistent store for your Domain model objects. An Application model on the other hand, is comprised of the objects that are part of the application infrastructure like Service, DAO, Gateway, etc. You won't store the Application model objects in your database. Instead, they form the API that becomes your 'software'.
# Posted By Paul Marcotte | 19/10/07 16:42 | Report abusive comment
Nick Tong's Gravatar Very nicely put Paul, thanks.
# Posted By Nick Tong | 19/10/07 21:57 | Report abusive comment
Kris Brixon's Gravatar I am a believer in starting with the View. Use the View as the communication tool to find out what is needed in the Database and Model. So, I guess I am more View - DB - Model - Controller. I gather to requirements with the View, then picking out the major data points from the View for the DB is usually easy, then figure out the Model and what BL it will take to make the View to DB work.

When the system is View - Controller - Model - Database, the customer will only ever see the View and ultimately the results of the product are in the Database, so the rest is just logistics.
# Posted By Kris Brixon | 20/10/07 13:43 | Report abusive comment
John Farrar's Gravatar 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. :)
# Posted By John Farrar | 21/10/07 17:24 | Report abusive comment
Russ Michaels's Gravatar In a perfect world you would decide, but in the real world it depends on the client/project.
Often the client has no clue what they want, and you have to design the database just to get a feel for what the model and view will actually be like.
I would also say that the VIEW would come before the model, as you surely want to create a wireframe for the client to approve before creating the model.
# Posted By Russ Michaels | 16/11/07 15:19 | Report abusive comment
Brian Kotek's Gravatar 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.
# Posted By Brian Kotek | 26/11/07 15:45 | Report abusive comment
Phil Duba's Gravatar I take the same approach as Kris above. I always start with defining the view states based on the customer requirements as I have found almost all of my applications deal with data entry and differing displays/reports on that data (I guess that's what happens when you live in an intranet world). I think I then design the DB first most of the time due to the heavy emphasis on reporting. Again, just my experience and I'm sure others have had the opposite experiences.
# Posted By Phil Duba | 26/11/07 16:07 | Report abusive comment
[Add Comment]
BlogCFC was created by Raymond Camden. This blog is running version 5.5.1.