2

Could please anybody explain what are pros and cons of this? I mean, without using ORM framework/JPA specification.

It concerns many-to-many and many-to-one relationships between entities. Imagine entity relationship

teacher - student (many-to-many)

or

doctor - patient (one-to-many)

My question is, whether we could put getPatients() method at Doctor bean or getStudents() at Teacher bean, or whether it should be POJOs and all this stuff should be placed in DAO layer.

I often see the first approach to be used in cases where the object model beans either extend classes that supply them with access to service / persistence Facades, or are injected by spring with them etc. It's advantage is, that one can call doctor.getPatients(); practically everywhere in the application instead of getting the results from DAO.

Are there situations in which the first approach is handy? Because I see a lot of cases where it is done exactly like that and I'm wondering whether it has a purpose or it is amateurism or the old style.

Jim Ferrans
  • 30,582
  • 12
  • 56
  • 83
lisak
  • 21,611
  • 40
  • 152
  • 243

2 Answers2

4

You can do anything you want, but the ubiquitous pattern is the DAO pattern. The point is to separate your concerns. If you have a domain object, chances are you have some business logic in there. Do you really want to put persistence logic in there on top of the business logic? You application will become less maintainable, less (easily) testable, and have more errors. And once you make one questionable design decision, more are sure to follow....

hvgotcodes
  • 118,147
  • 33
  • 203
  • 236
  • I also prefer the simple "Spring framework" way of strict concern separation, having pojos and dao layer. But some (modern / young) software I'm working with is going with the first approach so I'm wondering why. I just stay with the second approach as to my own app development, that's for sure – lisak Nov 04 '10 at 23:05
  • @lisak you should have a consistent approach across the dev team. – hvgotcodes Nov 05 '10 at 01:12
  • I'm doing my own projects, I'm too lazy to be employed :-) Thanks for reply – lisak Nov 05 '10 at 01:19
1

Follow the KISS principle. DAOs are great for abstracting the mechanics of persistence away from the domain logic. The domain objects simply carry state from one layer to the other, usually with very little business logic within them. This means that the domain objects (aka DTOs) can have lots of JPA annotations to indicate persistence with some kind of ORM framework, and also JAXB annotations to allow the DTOs to be marshalled easily to XML for transmission by a web service.

My general tendency is to have a single business object dedicated to operate on a single DTO to alter its state in some manner driven by the business rules. A service (which is the JTA transaction boundary) manages a collection of business objects and essentially forms an application transaction. This follows the general OOD principle of lots of fine grained objects with a very clear purpose.

Jim Ferrans
  • 30,582
  • 12
  • 56
  • 83
Gary
  • 7,167
  • 3
  • 38
  • 57
  • I also prefer a single business and persistence class dedicated to operate on a single DTO...but I never really think of a service as "JTA transaction boundary" which seems to be a really good practice...good to know – lisak Nov 04 '10 at 23:09
  • @lisak Thanks for the acceptance vote :-) You may want to look at this Stack Overflow question: http://stackoverflow.com/questions/1079114/spring-transactional-annotation-best-practice – Gary Nov 04 '10 at 23:41