3

In several projects we have been using the following layers:

  1. Action (has 1 or more managers)
  2. Manager(has 1 or more Daos)
  3. Dao

But most of the time the manager only calls the dao. We do use the manager class to prepare the date to be sent to the db or to prepare the data to be sent to the action(is this a good practice?).

  1. What are the responsibilities of a Manager and of the Dao classes?
  2. Do we have to have a manager for every dao or can we just use the dao directly?
  3. How do I handle situations where I need to use the functionality implemented in several Managers?

PS: I know that there is no golden hammer so I'll narrow it to the types of apps we do, generally webapps for banks.

Thank you

3
  1. What are the responsibilities of a Manager and of the Dao classes?

The responsibility of the DAO is the abstraction over data access. The responsiblity of the manager it to organize and execute the business logic of the application -- the manager uses the DAOs to accomplish this.

  1. Do we have to have a manager for every dao or can we just use the dao directly?

I would think you should be using the DAOs directly. Again, for the manager to accomplish its tasks, it might need to make use of several DAOs to manipulate data -- I don't see a problem with this.

  1. How do I handle situations where I need to use the functionality implemented in several Managers?

This could be a code-smell that you need to group together (refactor) certain logic or functionality into a new manager, or (although it might be extreme) another service layer on top of that to organize action among the managers.

2

This is just my preference:

  • Data Access Classes are responsible for each table
  • Managers are responsible for low level business logics and consistency between a few data tables. They use DAO for performing their duties.
  • Services provide higher level business services which needs collaboration between managers (manager of managers).
  • The services should be quite independent and granular which master a set of data and a business domain in the system.
  • A service should be mature enought so that it can be (and not necessarily will be) exposed over WebApi/WebService etc. as an independent service in the organization.
  • Services has a well defined interface and they can be injected to other objects for performing and e2e business case.
  • Services should not have many depenency to other services and they interact to none or just very few of other services for performing a e2e business case.

Not the answer you're looking for? Browse other questions tagged or ask your own question.