Relationship between Model (in MVC) and DAO

[Dan King]

What is the relationship between a Model (in the MVC pattern) and DAO? How are Models and DAOs supposed to interact? I was under the impression that models contain the business logic and interact with the database with help at times from DAO. However, I am working through a web framework example where:

1. The models seems to be nothing more than classes to which database tables are mapped to.
2. The DAO does all the interaction with the database.
3. The "logic" seemingly resides in the controller.

Have I misunderstood the role and relationship between models and DAOs?

Thanks.

[Campbell Ritchie]

Too difficult a question for "beginning". Moving.

[David Newton]

Moving again ;)

If the business logic was in the controller, IMO something's wrong--it really depends on what the example is trying to show, though. Most examples aren't thorough or completely "best practices", because it makes examples too large to digest.

Where to break up functionality is endlessly debatable. I personally keep my models very sparse, generally a DB mirror plus maybe other minor, but *tightly* coupled functionality, and that's usually it. Business logic stuff might go in a service, or into something used by a service, depending on how granular the app needs to be. (I'm big on separation, but also big on YAGNI.)

[Jimmy Clark]

Dan, don't think that all the examples you find on the Internet are correct.

In the Model-View-Controller design pattern, the Model represents business logic and business data. Data access objects (DAO) objects may be part of a Model, but they are not the only objects that make up a business object Model.

If this web framework example has business logic coded in whatever the Controller is, then it is not accurate.

The purpose of the Data Access Object design pattern is to shield the Model from "data" access logic, e.g. physical implementation of a data storage system. Business logic should be loosely coupled with infrastructure logic and data (CRUD) logic. Design patterns such as Data Access Object and Service Locator provide a guide on how to realize this.

[Ilja Preuss]

Sounds like an Anemic Domain Model to me: http://martinfowler.com/bliki/AnemicDomainModel.html

[Dan King]

James Clarks wrote:...In the Model-View-Controller design pattern, the Model represents business logic and business data. Data access objects (DAO) objects may be part of a Model, but they are not the only objects that make up a business object Model...

So if I understand this correctly, a "Model" can be comprised of various entities including ORM objects and DAOs; furthermore, business objects such as an ORM object can contain both the business data and logic.

If my understanding above is correct, then one could use the service layer pattern to give access to the "Controller" of business objects - i.e. ORM objects & DAOs - and thus the business data and logic?

[Raghavan Muthu]

James Clarks wrote:
In the Model-View-Controller design pattern, the Model represents business logic and business data.

Thanks James. I was also under an impression (so far) that the Model (mostly we use POJOs) just contain business data -- as some one said, it is a mapped representation of the db table (if it was an entity relationship).

Overall, having been using the business logic elsewhere. Definitely not much in controllers but in a Utility classes where it is appropriate!

[Hong Anderson]

Raghavan Muthu wrote:
Overall, having been using the business logic elsewhere. Definitely not much in controllers but in a Utility classes where it is appropriate!

Business logic should never be in Utility classes. You should have interface for all business logic. Utility classes should contain only non-domain concepts like StringUtils.

[Jimmy Clark]

The "data" objects in the Model do just contain business data. They may be a simple mapped representation of the business entity record in the relational table. Or, they may be something more complex. Typically depends upon the complexity of the business records, i.e. size, dependencies, location, etc.

The Model also includes other objects besides data objects. The other Model objects are business objects which contain business logic.

System objects from an EJB container, ORM framework, etc. support the Model, but do not contain your specific business logic.

[Hong Anderson]

James Clarks wrote:
The Model also includes other objects besides data objects. The other Model objects are business objects which contain business logic.

I think you're referring to Model components mentioned in Struts documentation which the model components can be Business Logic Beans like Session Beans.
http://struts.apache.org/1.x/userGuide/building_model.html

Currently I don't have enough information to discuss about what is "Model" in MVC. However, in Spring Web MVC Models generally contains data. Models in Spring Web MVC are meant to be rendered in views.

[Jimmy Clark]

Kengkaj, no that is not what I am referring to. An implementation of an application's Model can be done with EJB, but can also be simple POJO objects as well. Model-View-Controller is only a design pattern. It is not dependent upon any implementation technology, nor does it prescribe a specific way to implement it. It is only a design pattern and a guide.

[Hong Anderson]

MVC is an architectural pattern more than design pattern. Anyway that is not the point.
My point is what is the "Model" in MVC? Some resources like Struts documentation explains that "Model" is composed of data *and* business logic, in the contrary other resources like in Spring Web MVC design, Model is for holding data and View is responsible to render the Model, business logic is not a part of Model.

If I have more information about "M" in MVC soon enough, I'll discuss more about this.

[Jimmy Clark]

Actually, the Model-View-Controller object-oriented design pattern does not address software architectures. If you have a very small application that implements the MVC pattern, then it might seem to address the applications "architecture." However, in larger systems, MVC pattern only deals with the application "design", and has nothing to do with the architecture supporting the application.

Kengkaj, business logic is always part of the Model. It does not matter what implementation technology you choose. And yes, the purpose of the View is to display data extracted from the Model. This is true for any type of implementation. There is much more to the Model than just data however.

In a Spring implementation, business logic still goes in either POJO or Session EJB, i.e. the implementation of Model.

If you code business logic anywhere else, such as in Spring classes, then you create a severe artificial dependency on a third-party framework. This should be avoided at all costs.

[Hong Anderson]

James Clarks wrote:Actually, the Model-View-Controller object-oriented design pattern does not address software architectures. If you have a very small application that implements the MVC pattern, then it might seem to address the applications "architecture." However, in larger systems, MVC pattern only deals with the application "design", and has nothing to do with the architecture supporting the application.

In Pattern-Oriented Software Architecture Volume 1, MVC is classified as an architectural pattern.

James Clarks wrote:
Kengkaj, business logic is always part of the Model. It does not matter what implementation technology you choose. And yes, the purpose of the View is to display data extracted from the Model. This is true for any type of implementation. There is much more to the Model than just data however.

James, business logic is not always in "Model" in MVC. It depends on how we define what is "M" in MVC. From the view that "Model" contains business logic then yes, but there is "another" view that "Model" in MVC doesn't contain (most of) business logic.

James Clarks wrote:
In a Spring implementation, business logic still goes in either POJO or Session EJB, i.e. the implementation of Model.

It it not true, most of business logic is not part of "Model" in Spring Web MVC. You should have a look at Spring Web MVC design.
http://static.springsource.org/spring/docs/2.5.6/reference/mvc.html
Actually some business logic can belong to Model, but Model in MVC is not meant to contain all business logic.

James Clarks wrote:
If you code business logic anywhere else, such as in Spring classes, then you create a severe artificial dependency on a third-party framework. This should be avoided at all costs.

If you mean coding business logic directly in Spring Controllers, we shouldn't do that of course. But classes that implement business logic are not part of "M" in Spring Web MVC.

[Jimmy Clark]

Kengkaj, you seem to be misunderstanding the Spring framework AND the Model-View-Controller design pattern. In the Spring documentation, there is mentiond of a "model object", this is a business object, this contains business logic and this is a part of the Model. The Spring mechanisms for connecting to Model and for displaying data from the Model are complex. The framework provides a way to veiw data and to also connect to Model to execute business logic.

Aside, architectural patterns are design patterns.


The Spring framework contains supporting systems that will help with creating a MVC-based application. It does not contain specific Model components for containing business logic, and it should not. It does however provide support for displaying data extracted from the Model. This is one of the advantages over the Struts framework.

Keep in mind that the MVC design pattern is the same. Spring's implementation does not change the fact the Model is where the business logic goes.

13.1.2. Features of Spring Web MVC

Spring's web module provides a wealth of unique web support features, including:

Clear separation of roles - controller, validator, command object, form object, model object,
DispatcherServlet, handler mapping, view resolver, etc. Each role can be fulfilled by a specialized object.

[Hong Anderson]

James Clarks wrote:Kengkaj, you seem to be misunderstanding the Spring framework AND the Model-View-Controller design pattern. In the Spring documentation, there is mentiond of a "model object", this is a business object, this contains business logic and this is a part of the Model.

James, to me you are misunderstanding, Models in Spring Web MVC design *can* contain business logic (actually any objects, even Views *can* contain business logic) but they are not meant to contain all business logic, in other word classes in Services Layer or Application Layer (DDD) are not part of Model in Spring Web MVC.

You should read ModelAndView JavaDoc to get better understanding.
http://static.springsource.org/spring/docs/2.5.6/api/org/springframework/web/servlet/ModelAndView.html

James Clarks wrote:
The Spring mechanisms for connecting to Model and for displaying data from the Model are complex. The framework provides a way to veiw data and to also connect to Model to execute business logic.

What are complex? Displaying data is very simple for example if we're using JSPs we can use simple Expression Language to render the model.

And I don't know what you mean by "connect to Model to execute business logic". When developing web applications using Spring Web MVC, we inject services to Controllers, and in Controllers' methods we just write code to execute services and build Model and View and return a ModelAndView object. We don't connect to Model to access services whatever you mean by "connect".

James Clarks wrote:
Aside, architectural patterns are design patterns.

In POSA Volume 1, the authors separate architectural patterns and design patterns into different groups which have different descriptions.

Architectural patterns express fundamental structural organization
schemas for software systems. They provide a set of predefined
subsystems. specify thet responsibilities. and include rules and
guidelines for organizing the relationships between them.

A design pattern describes a commonly-recurring structure of
communicating components that solve a general design problem in a
particular context (GHJV95).

[Hong Anderson]

James Clarks wrote:

13.1.2. Features of Spring Web MVC

Spring's web module provides a wealth of unique web support features, including:

Clear separation of roles - controller, validator, command object, form object, model object,
DispatcherServlet, handler mapping, view resolver, etc. Each role can be fulfilled by a specialized object.

There is nothing there suggests that all (or most of) business logic are a part of model.
Model object just means a object that will be rendered by View.

If we think about it logically, it is not reasonable that why the documentation states that Spring Web MVC separate classes in Services Layer from the other objects. I cannot think of any Web MVC frameworks that force to implement business logic directly into Actions/Controllers.

However it would make perfect sense if the documentation means Spring Web MVC separates object that will be rendered by View from other objects, because in other framework like WebWork, object that will be rendered by View mix in Action classes.

We can map the aforementioned roles to Spring Web MVC interfaces/classes/methods as follows.
controller <-> Controller interface, Controller classes like AbstractController, BaseCommandController, SimpleFormController
validator <-> Validator interface
command object <-> setCommandClass, createCommand in BaseCommandController
form object <-> formBackingObject in AbstractFormController
model object <-> Model, ModelAndView, ModelMap
DispatcherServlet <-> DispatcherServlet
handler mapping <-> HandlerMapping interface
view resolver <-> ViewResolver interface

[Jimmy Clark]

Many misunderstandings arise when organizations start to use known/popular terminology and come up with their own definitions and mix in new stuff. Branding using "MVC" such as with "Jim's Web MVC framework" and "Fred MVC Web framework" is not good whey then attempt to alter meanings that are commonly understood to suite their purposes.


That said, when speaking about a Model View Controller application, all you have is this. So, Business Logic goes in the Model. It should not be in the View and it should not go in the Controller.


Kengkaj, what you have failed to mention in your posts about Spring Web MVC is where is the business logic coded? Specify this in terms of Model View Controller. Which area has the business logic?

(Kengkaj) Currently I don't have enough information to discuss about what is "Model" in MVC.

Keep your earlier (above) statement in mind.

[Hong Anderson]

James Clarks wrote:
Kengkaj, what you have failed to mention in your posts about Spring Web MVC is where is the business logic coded? Specify this in terms of Model View Controller. Which area has the business logic?

(Kengkaj) Currently I don't have enough information to discuss about what is "Model" in MVC.

Keep your earlier (above) statement in mind.

In Spring Web MVC architecture, most of business logic is not part of Model in MVC. To be more specific, most of business logic are "defined" outside MVC, but Controllers call the business logic "inside" their operations. As I explained, most common scenarios of Spring Web MVC implementations inject services (containers of business logic) to Controllers, and in Controllers' methods we call services, build model and return a ModelAndView (container of Model and View) object.

About my statement which you quoted, at first I didn't want to discuss about definition of "Model" in MVC because as we have discussed so far there are difference views about "Model" in MVC and I was not quite sure which is correct maybe both are correct they are just "variants" of MVC pattern.

Anyway, now I realize that one way to have more understanding about what we don't understand is to discuss about it .

[Jimmy Clark]

Sounds good.

In Spring Web MVC architecture, most of business logic is not part of Model in MVC. To be more specific, most of business logic are "defined" outside MVC, but Controllers call the business logic "inside" their operations. As I explained, most common scenarios of Spring Web MVC implementations inject services (containers of business logic) to Controllers, and in Controllers' methods we call services, build model and return a ModelAndView (container of Model and View) object.

I suggest to think about your phrase "business logic are defined outside MVC". In terms of the Model-View-Controller object-oriented design pattern, the business logic is part of the Model. So, what you are referring to as "services", these should be considered part of the Model. The business logic code that is in the "service" classes are part of your Model. AND, the data this is managed by the Spring Framework parts are also part of the Model.

Design terminology and "implementation details" terminology and "branding" or "advertising sometimes seem to all conflict with each other on the surface.