Forgive me, I still don’t understand For example:

package foo;
public @interface Bar {
// custom annotation
}

package model;
@foo.Bar
public class Person {
// model class with annotation
}

public class Test {
public static void main(String[] args) {
new model.Person();
}
}

Test (the client) needs not foo.Bar in order to compile and run.

As I state in the article, I prefer to work (though not always – depends if I’ve got a ‘clean slate’ or not among other things) by modeling the target domain first in a TDD fashion. The main reason is that you can usually actually model (i.e. test then write) a surprising amount of behavior in the system before you even have to consider an actual functioning persistence mechanism!

I guess that’s maybe another reason why I think declaring the-service-does-the-persistence to be the wrong idea – it’s putting the persistence methods ahead of the business problem domain.

Allthough the debate about DAOs is at least in its third round nowadays, it still seems to riling up a good part of developers minds.

For myself, i posted an answer to Adam’s very first entry on that subject but still wait for an answer … ;o)

You might want to take a look at

http://gleichmann.wordpress.com/2007/11/22/why-dao-wont-die/

Greetings

Mario

For your next point, I haven’t been so far imposed a legacy schema to work on, yet still I think that that is exactly the value ORMs should be providing. The mapping of the database relational data to the actual application model. If a whole another layer of classes, in addition to the metadata, has to fit between the ORM and the model then IMHO something is not very right.

To make myself clear, I don’t say that I always use pure entities in the client. It depends on the use case. For example if I had to display a complex grid of entities along with some of their relations and other computed details, I would probrably use a wrapper object (DTO if you will)..

Thanks for your excellent comment.

I think it’s a mistake that any client of a service layer has to also import, for example, org.hibernate.* – javax.persistence is a little bit less pernicious than hibernate, but only slightly. I really don’t like such persistence artifacts escaping the layers that are directly dealing with them. Why should a Struts action or a Tapestry page class (etc) be concerned about hibernate or any other database semantic? The point of layering is to isolate concerns. So for me, this means, if you want domain classes to also be your persistence model, no annotations (generally speaking). Cfg files I can live with, and in fact, over the past while I have increasingly leaned towards using e.g. .xbm configuration to map the domain classes to the database and have moved very much away from annotations to do it (this is also to do with what I see as the poor readability of the Java 5 extensions).

I also think, that it’s a huge mistake to assume that a domain model will exactly match the most performant or otherwise optimum relational model of the data. There is a fundamental mismatch – sometimes (and sometimes it’s not, in which case I’ll lean to the solution above). Also sometimes, you might have a relational persistence model forced on you by an already-existing database. To just assume, that the model that you can use to describe the functioning of the system (as for example illustrated in my rather twee taxi-ordering example above) is the same one as storage of the data is a big mistake (again, sometimes, not always). I find, as you develop a system, driven by its domain description, you want to be able to rapidly evolve the domain model in ways that may be incompatible with the slower evolution of a database structure and it’s normalised form (or for example, its highly optimised and specialised, relational form – especially if the database is already ‘legacy’ and can’t be changed as easily as the OO domain model).

If that was about DTOs I will have to disagree. I generaly avoid them like the plague and always strive to use my POJO Entities as much as possible.

“I find it disconcerting that the client layer would require a dependency on persistence infrastructure.”

Would you care to elaborate on that? As I said I use entities all the way through the client and have never had such a problem.

Search for “Misko Hevery” (a Test Engineer at Google) on Google Video to have your eyes opened. Those videos made me a TDD-guy, because I finally saw what was wrong with my code structuring.

No being able to replace an implementation of a specific concern e.g. by using DI and interface-driven-design, with a ’seam’/mock/test-spy is the dead end for testability. This is exactly what happens when you use EntityManager inside your services. Mixing Services with EntityManager-data-access leads to untestable code. No excuse, end of story.