Issues with the ActiveRecord Pattern and Statically Typed Languages
...Dynamic languages (and to a certain extend AOP) have the nice ability to decorate an object with additional features on the fly, without linking it "the hard way": you can then easily reuse your domain classes out of the persistence context...
Bernard goes on to say that this lack of ability with statically typed languages has given rise to DAO (DAL in .Net land) patterns to separate data representation and persistence technology. The solution to this in the statically typed world in his opinion is dynamic DAO generation which is already being done in JBoss Seam from generics and GORM in Grails.
Grails project lead Graeme Rocher adds:
...With GORM not forcing you to extend any base class and being totally unobtrusive this is all possible. The reality is Java frameworks force you to have a DAO layer, its not out of choice that they exist. Still this is not an insurmountable problem, I'm surprised there aren't more AOP based solutions around. In the meantime GORM is solving real problems...
AOP injection of DAO into domain object
I personally can live quite well with the situation that business logic that requires the persistence API lives in the DAO, while other business logic is defined in the domain object itself. But of course it creates an unnatural divide for the client of that business logic. The above AOP-based injection of the DAO into the domain object makes that divide almost invisible to the client - and all that from an old-fashioned statically typed language ;-)