when looking at your code examples, it feels like your way of implementing it, is very similar to how I did it before making this thread. This is probably true. The way I tend to approach software development is to do "just enough and no more". The example of the CRUD operations on a blog did not need any more than two classes plus a few very "thin" servlets, so that's all I wrote.
Instead of using servlets, I have my front controller which invoke my commands which can be seen as a variant of your "simple" servlets. Can you tell us a bit more about what code is in this "front controller"? One of the main reasons I wrote a very simple servlet (which does nothing except extract arguments into an object and call a domain method) is that there is as little as possible in the servlet which neads
testing. I like virtually all my code to be testable without the trouble and delay of packaging and deploying to a server, accessing remote URLs, etc. So I put everything in the layer "below" the servlets. In this case that is the BlogEntry and the DAO (so far).
Which layer does the servlets/command belongs to? UI controller? How do you avoid to put to much logic in the servlets/command classes? What I mean is that these are often specific for the view of a web page. I would still keep such behaviour out of the servlet/JSP/template layer. If you have more complex behaviour, just construct (or fetch from the servlet context it you want it to hang around) a domain object which does what you need. The code in the servlet should still be at most just: extract parameters + servlet settings, construct or initialise one or more objects, pass to a domain method.
If at all possible, make it even simpler, such as: retrieve an object from the servlet context, and call a method passing in the extracted parameters without creating a new object. The key is keep the servlet/JSP layer completely free of any decision making or business knowledge.
Would you mind showing a how a typical Pojo/domain class looks like or is it as simple as the BlogEntry class? Looks like typical Java Bean to me. This one looks like a Java bean because the scenario I "answered" had hardly any behaviour. Personally I would usually prefer classes with more behaviour than data.
I use an external API, called IPX for sending SMS-messages from my Blog. There are several lines of code required to be able to send a message, isn't it bad to put this in a command class? I'd start by creating a method which reduces that "several lines of code" to one method call with the appropriate parameters (maybe something like sendSMS(String destinationNumber, String message) and testing that on its own without any servlets, application classes, DAOs or anything else.
Then I'd look at where to put that method. This decision would depend to some degree on how complex the one-time setup process is for the SMS send. If the setup is "expensive", then I would consider placing it in its own class with the setup done in the constructor. That way the application can create a single SMS sender at startup and reuse it wherever needed. If there is no particular setup beyond that which is done for each message, then you might as well put the sendSMS method in the class which uses it.
As for the introduction of command objects, I've not seen anyting in the examples which would seem to need them yet. If I did, the servlet might look more like: extract a dispatcher object from servlet context, extract request parameters and pass them in to a dispatch method on the dispatcher object (as a custom object, a Map, or as raw String parameters). Any decisions, parameter processing, or creation of command objects would take place inside the dispatcher object. The dispatcher object is just regular Java (A POJO, if you prefer). That way the dispatcher object can be called equally well from your test code, from a servlet or even from other things such as a web service handler or JMS listener.
Following the example, if (rather than the simple approach in my post above of one servlet per action) we wanted a single servlet which decides what to do based on an "action" parameter it might look something more like:
The dispatcher dispatches requests to a command handler, each handler implemets a very simple interface such as:
And the dispatcher might look like:
Note that this is not really the Command Object pattern, as there is only one object of each handler class, shared by all requests of the same type. It's not much more difficult to create a new object each time, but (as I pointed out above) there's no obvious need yet.
You should also notice that the code is growing bigger. This is a particular worry as it has grown bigger for no increase in functionality. That's why I deliberately went for a very simple approach originally. Be ruthless about simplicity. If you don't need it
right now, don't code it.
On the up side, look at the dependencies between classes, though. The Servlet class(es) are the only classes in the system which know or care about anything from the Servlet API. The DAO class(es) are the only classes in the system which know or care about how or where the data is stored. Everything is just Java and can be tested and reused independently.
You can tell this separation works, because I was able to completely redesign the Servlet/HTTP layer without a single change to the BlogEntry or DAO classes. They still do their jobs just as in the original design.
Thank you for still having the energy to answer my posts. You're welcome. Any more questions?
darned HTML processing ate all my < and >
[ November 02, 2006: Message edited by: Frank Carver ]