从DAO组装域对象的逻辑应该放在哪里？

Question

I've read almost every questions here and a lot of related argument in the www, but still I'm not sure to well understand the point, and probably I miss something that is obvious to everybody else, since I think is quite a common situation...

Please, forgive my terrible english and the mixed up terminology, but I'm not really interested in differences/advantages/caveats of DAO vs Repository, I think this does not change the 'core' of the question, but maybe I'm wrong.

Obviously the example is too simple and every solution is easily overkilling, but think at this as a 'case' for a much bigger system.

Assume you have to build an application to suggest salesmans the people to call.

Each prospect has some 'textual' data (ie name, gender, birthdate, address, phone number, email,...), a photo and some history of his/her interactions with other persons and vendors.

Textual data resides on a Mysql table (person), the photo somewhere in the filesystem and someone has already released services that return a list of persons potentialy interested to be contacted given the salesman and a score for every prospect as a buyer.

I'll probably end up with the following:

1. A Domain Object Person, with name, phone number, address, email and photo. Setters and getters for all the property plus a methods getScore().

2. Two DAO, one for the mysql table and one for the filesystem.

3. A service to get the list of the prospect for the given salesman (the user of the application, left out of the scope of this example).

What is not clear to me:

1. The method getScore() in the Domain Object could directly call the service in the service layer? If not, why?

2. Do I need separate DTO for data coming from different DAOs?

3. If so, I need some sort of manager or 'super' DAO that own the logics about how to assemble the two pieces of information (ie get the URI from the mysql DAO, retrieve the file, load the picture)? Should this reside in the Data Layer or in the Service Layer? (seems to me should stay in the data layer, as far as it deals with were data are stored).

4. The output of the manager or 'super DAO' should be another DTO or could be directly the Domain Object?

5. If DTO, do I need a service who call the manager/super DAO and build up the domain object (in this case I assume the service will 'add' the score to the domain object to).

Is an articulate question, I know, but I'm not able to figure out how to design the solution.

Answer 1

A starting point for an answer:

1. I think the getScore() method should belong to a service not to a domain object
2. Matter of taste
3. That's a service IMHO
4. The output of the service could be a DTO or a domain object

In short (and in my opinion)

• domain objects are "dumb" classes (just here to map datas with objects)
• DAOs are here to fetch datas (and that's it)
• DTOs can be used as mediators between DAOs and services
• services are here to perform pertinent actions (by using dao), in you case calculating the score for example

Usage is allowed from bottom to top, ie. a service can use a DAO but not the other way around, to ease the possibility of changes (for example: DB backend change => DAOs updated and that's it)

=> community wiki