aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes MVC/DAO - How are they connected? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "MVC/DAO - How are they connected?" Watch "MVC/DAO - How are they connected?" New topic
Author

MVC/DAO - How are they connected?

Besjamain Greenaway
Ranch Hand

Joined: Dec 21, 2007
Posts: 45
I am making an application using MVC. In my view I have a JList which I want to populate with objects, brought on by pressing a button on the GUI. My question is this:
Where are the DAO's created and being referenced? Is it in the controller? I found this piece of an article somewhere that might clear it up, but I don't know how much truth there is in it:

"In general the model layer only contains model objects, also called data transfer objects (DTO's), which can be created, read, updated and deleted (CRUD) in/from the datastore using the logic of the data layer. The business logic, the 'controller layer' of MVC, uses the database access objects (DAO's) of the data layer to control and handle DTO's. The presentation logic, the 'view layer' of MVC, displays the DTO contents to the end-user."
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
The statements in the article are not correct. The Model (aka Business Model) contains and implements all of the application's business logic. In other words, business logic is coded in the business model objects. Business "entities" (aka records in the database) are processed by the business logic. Part of processing includes the CRUD statements mentioned above. So, a Data Accesss Object implementation is part of the Model.

DAO's are created by the code of the business logic in the Business tier.
Besjamain Greenaway
Ranch Hand

Joined: Dec 21, 2007
Posts: 45
The only thing I don't understand then is how model classes are created when there isn't any business logic yet. For example, I only have my view on which I can click a button to populate a JList. Somehow a call to the database has to be made to make the objects for populating the JList. Where does the call to the database happen? Do I need to make a model object so as to obtain a DAO?
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
How your Controller is implemented is unknown and well as how the Controller is receiving commands from the View controls?

Anyway, there is "business logic" however. Very simple logic at this point.

The data that is displayed in the View is business data, i.e. business entity data. It can be a list of products, a list of customers, a list of services, whatever.
In order to retrieve this business data from the database, you need logic, i.e. code statements, that query the database and extract the data. This is business logic.

So for example, if you are processing customer data, the you might create a business object named CustomerManager. The CustomerManager will have a method for getting the data out of the database, e.g. public final java.util.List getListofCustomers();

The DAO object used to get the list of customers is never touched by code in the Presentation tier. The getListofCustomers method uses the DAO to create the List (which contains the data).


Where does the call to the database happen? Do I need to make a model object so as to obtain a DAO?


The actual code statements that make the direct call on the database are written in the DAO class.

The methods of the DAO are called by the business object (Model). In our example, this is an instance of Customer Manager.

The business methods of CustomerManager are called by the Controller.

The Controller mediates communication between the Business Object Model code and the View code.

View --- > Controller --- > Business Object Model

Business Object Model --- > Controller --- > View
Besjamain Greenaway
Ranch Hand

Joined: Dec 21, 2007
Posts: 45
First off, I wanted to thank you for replying and trying to clarify. Secondly, I hope you don't mind me asking further

The actual code statements that make the direct call on the database are written in the DAO class.

The methods of the DAO are called by the business object (Model). In our example, this is an instance of Customer Manager.

The business methods of CustomerManager are called by the Controller.


Right, I'm with you this far But the problem I am having is this: When I start out with my app, I do not have any business objects. No CustomerManager objects in memory, nothing. They are created from the data in the database. So, in your example, you need to have a business object that makes a call to the DAO, in this example a CustomerManager. But this CustomerManager needs to be created first or else I won't have anything. I'm also confused as to how this would work with getting a collection of CustomerManagers. I guess you would need something else than one CustomerManager to get a collection of CustomerManager.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Sounds good.

It looks like you are attempting to just start writing code from the top of your head without a design or any
business requirements, presentation requirements, or service requirements. If you have these, then you have
business logic that needs to be coded. If you don't have any requirements, then you will have some difficulty
trying to implement the MVC design pattern.

The primary goal of the MVC pattern is to efficiently separate processing logic, presentation logic and business logic so
that code and be reused and/or easily modified and enhanced in the future. The key logic is the business logic.

The CustomerManager class would contain the logic (code statements) for retrieving business data from the database.
It is not created from data in the database.

In my example, the business entities are the rows of customer data in a database table.

There would be a CustomerDAO class that would encapsulate the code that connects to the database and extracts data.

A CustomerManager object and a CustomerDAO object are both business objects.



The getAllCustomers() method of the DAO would return a list of Customer objects.

So, in total so far, you have three business objects.

Customer - represents business data in database (a record or row in a table)
CustomerDAO - contains data access code to get data from database
CustomerManager - contains business logic (included API to get business data)

If you look closely at the getAllCustomers() method above, you will see that there is no database processing code in the method. Everything that directly connects to the database is in the DAO. However, the methods of the DAO are only accessed (called) by a business object.

Again, for emphasis, the only objects that call DAO methods are other business objects. View objects or Controller objects never call DAO methods directly.

The API of CustomerManager is what is exposed to the Controller.
Besjamain Greenaway
Ranch Hand

Joined: Dec 21, 2007
Posts: 45
Oh no, I got the whole shabang - requirements, use cases, etc. I know what my domain models are. The only thing I didn't know is how to implement everything with the database, etc. Or some stuff with GUI's. Basically, it is a sort of a roadtrip to figure all kinds of stuff out.

Anyways, I understand what you are trying to say. I felt it was weird to put accessing and retrieving something from the database in the controller, yet putting it in -for example- Customer didn't make sense because I didn't have one yet. The CustomerManager makes perfect sense. I searched the internet quite some but couldn't find anything that showed how it was done appropriately. Well, I did come across someone that made a static Data Access Layer class, from which everything could be retrieved from the database. So there would be all kinds of methods for CRUD'ing Customers or Accounts.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

James' suggestions are ones which I follow as well. The DAO pattern is quite popular. Keep in mind on your travels that it isn't the *only* way. You mentioned accessing the database from your Customer object. This is considered the Active Record pattern and is very popular. You'll see a lot of scripting frameworks like Rails, Grails, CakePHP, etc that all use some form of the Active Record pattern.

I prefer the DAO patter, like I said. I just didn't want you to think that different patterns are wrong. They aren't. They are just different.


GenRocket - Experts at Building Test Data
Besjamain Greenaway
Ranch Hand

Joined: Dec 21, 2007
Posts: 45
I was just searching and reading upon what you say - and I just had another lighbulb moment. I was searching on DAO and Manager, and I hit upon a site that says this:


Here is a sketch of a DaoManager:

public class DaoManager{
protected Connection connection = null;
protected PersonDao personDao = null;

public DaoManager(Connection connection){
this.connection = connection;
}

public PersonDao getPersonDao(){
if(this.personDao == null){
this.personDao = new PersonDao(this.connection);
}
return this.personDao;
}

}

In this sketch only a single DAO is obtainable, PersonDao, but you could easily add more DAO's along the same model.

Notice that the getPersonDao() method isn't synchronized even though it returns a kind of singleton. The DaoManager is not intended for sharing between threads, so no synchronization is inserted. Doing so would be quite easy though.


This looks like it could form a factory of some sorts. Could I be right if I would say that your CustomerManager is a sort of factory?
Bauke Scholtz
Ranch Hand

Joined: Oct 08, 2006
Posts: 2458
Article text is fixed to fit the general and basic understanding. I, as being a diehard MVC developer, started to see MVC less or more as M(MVC)C which is in this case not quite correct.

Thanks for the pointers and feel free to comment the new text. I am always open for feedback.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Calling a class *Manager is a big code smell - it's a very generic name that can mean everything and nothing. In my experience, before I can come up with a name that better describes the responsibility of the class, I haven't thought enough about what the responsibility actually is. (Those classes are also quite prone to becoming god classes...)

In your case, it sounds like it might be something along the lines of a CustomerRepository?

I highly recommend the book "Patterns of Enterprise Application Architecture" for this kind of design questions.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Could I be right if I would say that your CustomerManager is a sort of factory?


No this is not right. Don't confuse the DAO example you found on some web page to the example in this thread. The CustomerManager object in my example would be designed to handle all of the business logic for dealing with customers and whatever they may be invloved in, e.g. applying sales discounts, matching up demographic data, up-selling, cross-selling, etc.

There is no factory here, just business logic that is based on business requirements.

In a MVC-based application, the business logic is coded in an application which can be executed from multiple Views, e.g. cell phone, command-line, web browser, EIS, etc.

Model -----> Controller-1 ------> View-1

Model -----> Controller-2 ------> View-2

Model -----> Controller-3 ------> View-3


The Model application code is the same and does not change. Each View has a Controller which mediates between the Model and the View.


The ultimate benefit is that the code, the business logic code (Model), does not have to be modified for changes in the View. The View and Controller do not contain any business logic.

The implementation of the Data Access Object design pattern is part of the Model. And, only business objects communicate (use) the DAO objects.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
James Clark wrote:Each View has a Controller which mediates between the Model and the View.


That's a common misunderstanding of MVC. The actual responsibility of the Controller in MVC is to accept input (like incoming requests), and to translate it into actions in the Model and/or the View. The View is well allowed to listen directly to the Model and depict changes there directly, without any mediation by the Controller.

The whole idea behind MVC is to decouple the three aspects of business behavior (Model), input channel (mouse, keyboard, voice...) and output channel (text, graphhic, sound...) so that they can be changed independently of each other.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Ilja Preuss wrote:
James Clark wrote:Each View has a Controller which mediates between the Model and the View.
The whole idea behind MVC is to decouple the three aspects of business behavior (Model), input channel (mouse, keyboard, voice...) and output channel (text, graphhic, sound...) so that they can be changed independently of each other.


Unfortunately, that is nearly impossible. The view and the controller always become tightly coupled.
Bauke Scholtz
Ranch Hand

Joined: Oct 08, 2006
Posts: 2458
That each view has its own controller is not always right. In for example JSF there is only one controller.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Bauke Scholtz wrote:That each view has its own controller is not always right. In for example JSF there is only one controller.


That's not entirely true. In JSF, it is true that a servlet controller is handling incoming requests, but really the backing bean is also somewhat of a controller. So JSF has a Model/Controller hybrid approach because it is the backing bean that is determining the outcome of a request. I don't know of a single theoretically true MVC framework in existence. Everything bends the rules and mixes the layers so that it works.
Bauke Scholtz
Ranch Hand

Joined: Oct 08, 2006
Posts: 2458
Exactly. It's less or more the M(MVC)C approach I said before.
Technically, according the classic MVC pattern, the FacesServlet is the sole controller.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
In terms of implementation, there can be one Controller, there can be many Controllers.

In terms of implementation, there can be one View, there can be many Views.

In terms of implementation, there can only be one Model.

*** Direct communication between the Model and a View is discouraged and a deviation from the design pattern. ***

There are many different ways to "implement" the Model-View-Controller design pattern. It is only a design "pattern" and there are no specific rules which dictate how it is implemented. It is only a guide. That is all.

The basic concepts are input data is captured by a View. A Controller receives input data and forwards to Model for business logic processing.

Depending upon requirements, if I needed to submit data to the Model application, I could send an ASCII text file via execution of a command line. If needed, I could also enter data from a web browser GUI interface.

A good example of this is the transmission of administration commands for Websphere Application server. An individual can both send commands from a command line interface and can also send the same commands from the web GUI in a browser. The code (Model) that processes the commands is the same, only the View and the Controller are different.
mjay rehan
Greenhorn

Joined: Jun 01, 2009
Posts: 1
Hey James,

"Customer" alone can be accessed by a controller?..it doesnt have to be through "CustomerManager"? for instance there is a customer form on any view, and controller use customer object to get/set form info for it.
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Gregg Bolinger wrote:
Ilja Preuss wrote:
James Clark wrote:Each View has a Controller which mediates between the Model and the View.
The whole idea behind MVC is to decouple the three aspects of business behavior (Model), input channel (mouse, keyboard, voice...) and output channel (text, graphhic, sound...) so that they can be changed independently of each other.


Unfortunately, that is nearly impossible. The view and the controller always become tightly coupled.

If you have used Spring Web MVC you will know that is not true .


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Vijitha Kumara
Bartender

Joined: Mar 24, 2008
Posts: 3855

Ilja Preuss wrote:The View is well allowed to listen directly to the Model and depict changes there directly, without any mediation by the Controller.


I think you mean, for the view to display (Customer)data it needs to access the Model (in this case Customer) ?


SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
Vijitha Kumara wrote:
Ilja Preuss wrote:The View is well allowed to listen directly to the Model and depict changes there directly, without any mediation by the Controller.


I think you mean, for the view to display (Customer)data it needs to access the Model (in this case Customer) ?


I believe he means model will send notification to view. You can read Observer pattern.
 
Don't get me started about those stupid light bulbs.
 
subject: MVC/DAO - How are they connected?