0

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 (i.e. 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 (i.e. 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.

enrique-carbonell
  • 5,836
  • 3
  • 30
  • 44
Marcoc1712
  • 321
  • 2
  • 10

1 Answers1

0

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

  • HI,tanks for your answer, but I'm still a bit confused: – Marcoc1712 Oct 14 '14 at 19:40
  • DAO = access to the data, DO = representing the data, so not the same class IMHO –  Oct 14 '14 at 20:17
  • Alan, I've read the aticle and I agree with the author when claims the anemic model bring to procedural style design, but this is not the point of my question: Assume you put all the logics you can in the Domain Objects and use services only for transactions that you could not easily reconduce to a specific one, I'm still not sure is a good Idea to put into DO the logic to assemble itself form DAOs (or DTO by the way), at least when you have more than one. Question is: MUST I have separated DTO and DO also when they are in a one to one relation vs. could/should I extend DTO to add logics? – Marcoc1712 Oct 14 '14 at 21:08
  • Removed previous comments, they was confusing due to a mistake. This is the correct version of the question: Could the DTO and DO be the same object (maybe implementing different interfaces or letting the DO extends the DTO) or I should avoid this and always rebuild the DO from DTO received from DAOs by the server? – Marcoc1712 Oct 14 '14 at 21:16
  • Again IMHO, DTOs are tools (wrappers) so there should be no inheritance between DOs and DTOs. As an example, imagine you need a list of your `Person` with their score (sorted by score), one would use a DTO (lets call it `ScoredPerson`) containing 2 fields `Person` and a `score` and implementing `Comparable<>` –  Oct 15 '14 at 05:51
  • Agree, but since the DO person is first an interface and say ConcretePersonis the concrete class implementing it, why could not ScorePerson be an Interface and ConcretePerson implement also it? – Marcoc1712 Oct 15 '14 at 09:36