October 2002 - Posts
James Strachan agreed with my post about domain data, and made some suggestions for the Java world.
Chris did not agree with my comments about Java and Open Source projects. Niel got my point.
To be able to mature, you need a solid foundation, and too much options is not a solid foundation. It is like marriage ;). You can fool around for a while, but if you want to get to the next step, you need to make a choice and move on (errr.. some of you will still prefer to have a couple of more 'options' ;)
In 5 years, I don't want to have 5 Java web application framework options. I want to have a solid (and 'good enough') framework and use my energy in solving other challenges.
Rickard Öberg did an in depth revision of Middleware Company's Pet Shop application did not like what he saw.
This PetShop story is far from ending...
Patterns of Enterprise Application Architecture.
I tend to rely more on the Transaction Script model. The biggest problem with Transaction Scripts is the duplication of logic. But through copious amounts of refactoring, I can keep that at a minimum. Transaction Scripts allow me to treat one page as an application. It knows how to get the data it wants and how to display it. That's it. It doesn't use an object model that might have to make use of 4 other objects in order to get all the data you want to display.
[News from the Forest]
That's the approach we follow in DeKlarit. Your domain classes are not the usual 'normalized' domain classes, but unnormalized views of the data required in a transaction (i.e., the Order class has a CustomerName). The good news is that DeKlarit manages the 'duplication' itself, so you don't have to worry about it.
If you don't like it, you can also work with a more traditional Domain Model.
There is a new benchmark in the Java side for the Pet Shop application. It was made by 'The middleware company', the company behind TheServerSide, and this time they tuned it for performance, and it was much faster than the original Sun implementation.
.NET performance is still much better than J2EE's. I wonder why ;).
Tim Ewald makes the
case against SOAP Section 5 Encoding which the WSI-I was very smart to exclude and prohibit from their
basic profile [
Sam Gentile's Weblog]
The quantity and quality of Java Open Source projects could be it worst enemy.
Russell Beattie said it quite well. There are too many options in the Java world, and even if they could be better than the .NET ones, this is not good for Java. One of the biggest fears any developer/IT manager/CTO has, is to build applications on top of technologies that won't succeed, and there is no room in the future for 5 persistence engines, 5 web application development frameworks, etc.
On the other hand, the 'safe bet', that would be the 'standard' J2EE set of technologies is being challenged with these Open Source projects, so it's not clear that is _that_ safe. These open source projects are very appealing for developers, who are the ones that usually make development platforms succeed.
There is an article in the TheServerSide about designing your applications with a layer of 'Plain Old Java Objects' representing the domain data, and an EJB layer to handle the persistence.
Even if I don't really like the complete solution presented in the article, I think it's difficult to not to agree with the idea that we should use domain classes that are totally independent of the persistence strategy.
I want to use the same Customer class in my Windows client code, in my web application, in the middle tier, in the web services layer, etc, etc. Separating Data From Architecture is a good article about this.
Working with a persistence layer that stores objects to the database is nice, but if you build your application on top of that classes, you are stuck with that persistence implementation, which is not a good idea. If you want to use a persistence layer, use it to persist your domain classes.
I think .NET got it right. I really like the DataSets idea, even if today they do not interop via web services (I hope they will someday), and even if they are too 'relational'. DataSets are 'domain classes on steroids'.
Designing Data Tier Components and Passing Data Through Tiers is a very good MSDN article describing the strategies available in .NET.
TheServerSide Now Publishes News via RSS Feed
A good source of information to keep up to date with the Java world.
There is an electronic version of this book available. I'm not sure if the previous versions were also available online.
We've been using internally the printed version of this manual, and it's quite good. Anyway, it's like coding conventions... it's not important if it is not perfect, but you should have one.
More Posts
Next page »