views:

113

answers:

4

How are models and DAOs supposed to interact? I'm in the process of putting together a simple login module and I'm unsure where to put the "business logic." If I put the logic with the data in the model, how would I access the logic?

Currently, I have:

  1. A controller that receives form data
  2. A model that is a simple reflection of a db table
  3. A DAO that using hibernate performs a simple select query, based on the form parameters received by the controller.
+2  A: 

The controller has to find/load the business object matching the request and execute it. The Strategy Pattern is useful in this. The business object on its turn has to get a handle of the DAO and the model to do the process.

E.g. (pseudo, inside a front controller servlet)

public void process(request, response) {
    View view = new View(request, response);
    Action action = ActionFactory.getAction(request);
    if (action != null) action.execute(view);
    view.navigate();
}
BalusC
I agree. I think of the controller as what defines the API between a view or service and business logic. Putting business logic in the controller pushes it towards being a "god" class.
memnoch_proxy
Rather than using the "Strategy Pattern," what about using domain objects (models and DAOs) with a service layer? From what I understand of the "Strategy Pattern," it doesn't quite fit.
Dan
You can for example hava a `Map<String, Action>` wherein the `String` part denotes the pathinfo (and if necessary prefixed with the request method) and the `Action` denotes the appropriate action class (which can be statically loaded at once using annotation or marker interface lookups).
BalusC
+1  A: 

Put it in the controller. Controller is like a heart of your application where most of the logic is written.

It's not good to put the business logic at Model Level.

Kushal Paudyal
A: 

You might want to take a look at some of the answers to Best designs for breaking down business logic and data layer when they seem to overlap?

matt b
A: 

A typical layering would be like this:

  • Controller
  • Model
    • Business Layer
    • Data Layer (DAO)

The model would contain both the business and data layers while keeping those layers loosely coupled to the extent that makes sense. The controller would access the model, which in most cases should be the business layer. It's preferable that the controller not have direct access to the data layer, but it happens quite a bit in smaller apps.

Michael Maddox