Here is the small description of design strategy we followed for the project. We had Value Objects representing the database tables. This Value Objects were passed to and fro from the client to the server. In our case client is the application client.
This Value Objects extends to a interface. We had a EJBCommandServer as the Stateless Session bean. So the CommandExecutor just sets the values in to Value Objects through setter methods. This Value Objects is passed as interface object to the server as a argument in execute method in Command. Thus the getter & setter can be reduced.
The normal EJBDesignPattern is good in its isolated sense where in we dont have Value Objects.
This sounds intriguing but I'm unable to follow your train of thought entirely. Can you provide some additional details?
I don't follow you completely either. How about a UML diagram?
Though reducing the menace of getter and setter sounds great but actual concept on how this is being done will be of great help. The brief explanation though makes one excited but leaves one confused, as to what exactly you have done. A UML design pattern explaining the concept in detail would be great help.
This idea sounds intresting. I am not able to follow you. please give detailed explanation.
Sorry for the short description. I had provided detailed description in another text box below the short description text box but some how the other detailed one is not figuring in the text.
The CommandExecutor calls the executeCommand and passes the Command as argument in EJBCommand Pattern thus we need to have get/set in Command. This works fine and optimized when we have only EJBCommand. But the most projects i have worked, most of them had value objects. So my pattern is for those projects which has value objects in addition to EJBCommand. According to this EJBCommand-ValueObject Pattern one needs to pass even the ValueObject as another argument to CommandServer along with the Command. The CommandServer will invoke the Command with ValueObject as argument. After processing the CommandServer returns the ValueObject.
Just needed to rephrase the last para.
According to this EJBCommand-ValueObject Pattern one needs to pass even the ValueObject as another argument to CommandServer along with the Command. The CommandServer will invoke the execute() method passing it the Command and the ValueObject as arguments. After processing the CommandServer returns the ValueObject.
Hope, this is what you really meant.
Thanks Dimple for rephrasing the last para.
This sounds very similar to a pattern we use, except that our value objects from the client do not have to implement any interface, they just have to be serialisable, the infrastructure handles them as 'Objects' and passes them on to the appropriate business process which 'knows' what type they really are, after all why should the infrastructure need to know anything about the structure of the objects being passed around.
i used this kind of design two years ago, but I didn't know it's such a nice pattern:) ... i just didn't like the "CMP bean+remote interface" design used by most of the parts in that project ... old times :)
and the concept is pretty simple, I just don't understand why are so many questions here? maybe you peaple want an UML diagram with the EJBCommandServer & CommandExecutor used by the autor? ... don't you think that's copyright violation?
this open-source stuff makes everybody lazy :)
which getters/settes have been optimized here ? Its all the same. I dont see the power of it.
It is described in the IBM Redbook for Websphere 3.5.x app server.