Learning OO is such a disappointment. When you go from the models and into the code, you pretty much discover that it is all bunk, anyway. In your neat customer-order-product design, each entity explodes into circa 10 artifacts if you implement it in J2EE, or gets fragmented into mostly pure data management if you use .NET. You can hardly find the classes again anywhere in the implementation. What went wrong?!
In an ideal world, you would be able to write the business code as naively as you wanted to. “I have a customer class with a (bidirectonal) collection of orders, a few methods, etc. etc.” This code should be full-fledged, honest-to-god working code. Write it, test it, tune it. Don’t worry about the infrastructure. Then, write your infrastructure rules. “Oh, the customer lives on a clustered application server. It is loaded from the database like so. When a client uses it, transmit the customer along with all the orders to the client. The calculateTotalOrders method should run on the client, but the consolidateOrders method should run on the server”. This code should be as compact as possible, with as few possibilities for error as possible, and as good defaults as possible. Heck, the application server could even calculate statistics and automatically deploy it after doing some “realistic simulations”.
Why isn’t this possible? Well, it is, but it is not done. All frameworks are infrastructure centric, and the business code has to bow to the infrastructure. You wanna distribute this class? Create an interface (and a home interface for EJBs), and make sure all the methods throw exceptions. You wanna cache data for this object on the client side? Well, just implement the Data-Transfer Object pattern (%!@#!). You wanna test your code? Well, fire up the 200MB application server, wait 2 minutes for you #@$!!! to deploy and hit it. This is not what the state of the art should be.
And this is where MDA comes in. With MDA, the focus is on the business entities. You can have the plumbing all generated for you. The Platform Independent Model lets you draw up your customers, orders and products. A good MDA tool will then generate the forest of artifacts required to realize each entity in a J2EE architecture. This is roughly 10 files per entity. This is kind of like applying a fire hose, a chainsaw, and generous amounts of duct tape to the insufficent technologies, but it works. If J2EE was designed to be used without tools, they did a very poor job of designing it. I think technology that is designed to be usable without tools is inherently better, but you have to use what you’ve got.
Do I like MDA? Heck, no. Is it the best we have got with the current state of technology? Heck, yes. Do I want to use it when I am forced to do J2EE? Heck, yes!
Subscribe (atom)