Notes on the expert panel
After lunch we had the expert panel taking questions from attendees. The first question was about domain models and the role that they play in application architecture. In particular, the term Anemic Domain Model was tossed around. To paraphrase Martin Fowler, this happens when a domain model exists but does not contain any behavior; instead the behavior is defined in the service layer. Using the service layer instead of the domain layer for behavior is more procedural than OO. The hard core OO crowd is not too thrilled about this, especially for complicated apps that could benefit from a strong OO model. However there are some real world constraints that make this architecture difficult. One roadblock is that it is difficult to do dependency injection on domain objects, especially when they are created with an ORM tool or with the new operator. Another example is with Apache digester: we have an application that creates domain objects based on an XML stream, and these objects have behaviors that require DAO access. The only real way to do this right now with Spring is to have a static reference to the bean factory. (Yes, this is a really ugly hack) However, with the improved AspectJ integration that is going into Spring 2.0, performing DI on domain objects will be much easier. This will allow domain objects access to the DAO or services layer, which should make it easier to associate behavior with them.
Another discussion was started about using annotations and whether frameworks that rely on them should be considered “light weight” since the annotations tie them directly to the framework. This question got Rod on his soapbox about why using annotations for configuration are not such a good idea. This reminded me of a posting by Craig Wells on this topic a few days ago. The argument is that annotations are meant for class level configuration, not object based configuration. If configuration is set up in the Java class file, then it becomes very difficult to configure individual instances of that class.
I have not had the chance to move our middle tier to Java 5 yet, so I do not have much experience with annotations. However, I do have to say that I tend to agree with this idea. In our project, we have an entire layer of mock DAOs that we swap during testing to test our service layer. Since these configurations are defined externally via XML, we’re able to swap out DAO implementations for our services without affecting the services at all. I suspect this would be more difficult with annotations since it would require modifying the Java source itself instead of just configuring the application context to load one set of DAOs for testing and another for deployment.
Of course this would not be a Java conference in 2005 if no mention of Ruby on Rails is made. The Spring team does admire the concept of convention over configuration although it is more difficult with a statically typed language like Java. However, the developers are very interested in dynamic language support in Spring, and they are also looking to simplify the MVC configuration for Spring 2.0.
The concept of setting up a foundation for ownership of Spring (ala Apache) was also mentioned to be in the works. This should be set up by Q1 next year.
