Spring Roo with a services/DAO architecture

[raul.arabaolaza]

Hi,

Although I prefer using a Rich Domain model in most applications I wonder how well it suits in an enviroment like OSGi where all seems to be service-based and (I think) JPA have some interesting challenges.

This can be generalized to any modular environment, and modular java seems to be a very hot topic this days.

BTW maybe it´s too early to ask this?? Roo´s in it´s RC 2 version yet and it already have a bundlor add on.

Regards, Raúl.

[Ben Alex]

90% of the time I would expect the persistence methods to be called from other layers, like tests, services or controllers. Sometimes an entity might have a good reason to lookup some information, but it's the exception rather than the rule because chances are the entity holds an association to another entity via normal Java references and therefore can depend on transparent persistence (eg lazy initialization).

I'm actually a big fan of using JPA features to ensure entities aren't particularly aware of making explicit persistence method invocations. To achieve that you need to use the various JPA features that exist. I believe the function of repositories is diminishing as we end up with smarter APIs like JPA that use clever language features (dynamic proxies, AOP, load-time weaving, instrumentation, inter-type declarations etc) to address the individual issues that historically motivated a repository or DAO layer. Dedicated repository/DAO layers probably still make sense if you're trying to do JDBC alone and don't have the benefits of an intelligent persistence layer like JPA that sorts out many of the technical issues that repository/DAO layers focus on.

[ccanning]

I think this thread deviated from the original question "How would one write a 3rd party addon to support service and repository layers" and became a debate about the validity of such a design. If you come from the perspective of "this is the current architectural design", then the pros/cons of it doesn't help much. Many people have chosen the service/domain/repository pattern (Spring 2.x even promoted the repository with @Repository). Also, many people have functionality that exceeds the simple entity manager and basic crud operations. I think it is valid to describe a way for people to extend the framework to support this stuff. If a framework forces someone to conform to a single methodology/design, then it won't be very useful for the masses especially legacy/enterprise applications) or is the framework designed to compete with simple web generation frameworks.

[Ben Alex]

The EntityMetadata was designed to abstract the acquisition of persistence methods from any location, including both the entity and other types. https://jira.springsource.org/browse/ROO-287 provides the necessary plumbing so third parties can write add-ons to generate a repository/DAO layer. If someone wanted to work on a third-party add-on which provided a separate repository/DAO layer, I'd be receptive to making whatever changes are appropriate to our current base add-ons to support it (given EntityMetadata was intended to support such abstraction in the first place).

[ccanning]

That would be something we would need. I am in the process of learning ROO for the purposes of potentially bringing it in-house as we have our own base repository that provides a lot more functionality then the standard EM. Also, our services are based on generated data objects, so putting persistence in that layer is not an option. Is there any documentation on writing a 3rd party addon yet?

[Ben Alex]

https://jira.springsource.org/browse/ROO-301 represents the feature request for separate DAO/repository support. Please vote for the issue if you'd like it.

[Steve Shapero]

I've got a pretty nice domain model going in roo and, having written many "old school" style DAOs, I'm totally sold on the Aspect-driven approach, it satisfies all my requirements beautifully. But I am new to the whole DDD approach. I've seen plenty of rails code with 2000+ lines of code in a Model class that is just a wasteland of pure code entropy waiting to happen. To avoid this, similar to what seems to be encouraged in grails, I'm planning on creating a com.mycompany.service package that contains things like BigBusinessLogicConcernService. Theses "services" will be responsible for performing complex business logic that involves 2 or more entities. These services can then be injected into controllers (just like grails again) so that concerns remain correct in the different layers.

This is the approach that seems correct to me but I'm interested in hearing others feedback on this concept - given that I'm already 100% down with the DDD Kool-aid and have no interest in traditional "DAO" like objects etc.

Thanks
Steve

[Ben Alex]

I totally agree that once you start getting a lot of business logic you should factor it out into separate classes to improve testability, maintenance and understanding. I tend to use a services layer where multiple objects are involved that do not already hold references to each other.

[olivier]

How does this rich domain model get serialised during an RPC/JMS call ? I noticed that the EntityManager is transient so it does not get serialised. Also when the service receives that entity and deserialise it, there will be a need to inject an EntityManager to activate persistence. Is this something that the container will cater for automatically within JEE or is this something that needs to be done manually ?

[Ben Alex]

Roo uses Spring Aspects, which defines an @Configurable annotation. Roo projects use Spring Aspects as an "aspect library", meaning AspectJ performs compile-time weaving of advice defined in the library. @Configurable has a pointcut which causes dependency injection on both construction as well as (de-)serialization of an object. Therefore the EntityManager will be reinjected when deserializing.