Joseph Fifield wrote: > Sorry if this a dumb question, but: What do you mean by using the > command pattern instead of session facade/value objects? Can you > elaborate on that?
Yes I could, although only briefly (this should be covered by an article or two really). The usual reason to use session facades is to provide a point of entry into the EJB layer and also to facilitate a one-call optimization where a single network call can result in multiple operations on EJB's. The problem with it is that often this leads to "dumb" copying of methods on entities and also to excessive creation of value objects, e.g. if you want to list data from 100 entities you make a call to a session facade which copies data into 100 value objects and return that. An Other Way to do this is to use the command pattern along with the visitor pattern. For example, one common operation is to simply get the data of an object for display. Create a command with a known method that takes a call-back to an entity, to use for the visitor pattern(e.g. "execute(EntityBean)"), and which has get/sets for the data to be retrieved and which mirrors those of the entity. Add a "getData(Command)" method on the entity (preferably in a base class of course) that you can send this command to. The entity can then call "execute(this)" and the command can extract the data it needs. The web layer can now use the command itself as a value object and display it. If the web and EJB layers are in the same VM a huge improvement can be made: only one command may be used to iterate over all entities. It is simple to make a custom iterator that for each iteration calls the next entity and retrieves the data for it. Since it's all local there's no extra overhead for making many calls to EJB's (and besides, that overhead would exist for the session facade as well). So instead of creating 100 value objects we have created 1 command, yet the same operation has been performed. This is the general idea. It can be extended to pretty much any operation. Another good thing compared to session facade is that a command can obviously have as many result variables as needed, whereas a method in a session facade can only return one thing (and if more is needed you need to create a custom value object for that). I am using this pattern exclusively in the new TheServerSide.com portal code, and it is working quite well. In the beginning I used WebWork actions as commands, but have switched now to custom interfaces that are more streamlined for this particular task. I have basically three layers of code: 1) WebWork actions that interact with JSP's/HTTP 2) Command/visitor actions 3) EntityBeans 3.5) DAO's There's the odd session bean as well for some generic non-object tasks such as managing the database, but most of the EJB-code is in entities. Since many commands can be put into the same class there's not an explosion of classes, which is a common risk with using the command pattern. That's the gist of it anyway. /Rickard -- Rickard �berg Author of "Mastering RMI" Chief Architect, TheServerSide.com The Middleware Company - We Build Experts! _______________________________________________ Webwork-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webwork-user
