This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I'm new to the JCD (and new to this forum, so hi! and have spent the past week thrashing out my design for my B&S assignment
While pondering England's depressing defeat yesterday evening (in the pub afterwards) I suddenly had an inspiration of brilliance regarding the command pattern.
My thinking here is that I could use the command pattern to encapsulate each request the client makes to the server therefore reducing the coupling between the two.
Now, if I was using sockets for my project I wouldn't hesitate in moving forward with this design - it saves having to worry about a protocol (too much anyway) and is easily implemented.
The question is though, is my original idea of defining an interface at the server end and adding a business delegate layer to control access to/from the server more suited to my RMI approach. (In other words, calling update, find, read etc... directly from the client). After all, with RMI I effectively have direct access to the client so I'm questioning whether the command pattern is trying to go against what RMI is all about or is it in fact a brilliant idea which affords easy future expansion/development, employs another buzz wordy pattern for my choices.txt and tidies up how my client and server interact.
I guess this could be seen as more of a general RMI 'best practise' question but one that I'd be interested to find people's views on.
Personally I think that the command pattern is not a very good fit for RMI. One of the major advantages of RMI is to make it appear to client programmer that a remote method is local. But when you add the command pattern you are stepping back from that direct access - to my mind this defeats the purpose.
This was exactly my concern - the big question now is to justify using it over RMI, which I'm not so sure I can.
I like the some of the advantages the command pattern approach affords (especially regarding its simplicity, from a maintenance perspective and for future expansion) although I suspect I'm going to have to go with the sockets approach as, like you say, it goes against RMI's grain to restrict the remote call to one 'doIt' type method.
I'm now trying to think of dis-advantages of going down this route, although am struggling a little.....
*insert help below*
author and jackaroo
It sounds like you are trying to work out how to use the command design pattern in your solution, rather than working out a top level architecture and then deciding which patterns fit within it.
Personally I think this is dangerous - trying to force the use of a particular design pattern can result in awkward and/or hard to understand code.
If you really wanted to use the command design pattern in your application, you might want to look at whether it can be used for communication between the various components of an MVC (and, if you use the observer design pattern between the model and the view, you may find that it almost forces you to use the command design pattern - although that is not the only place in an MVC that can use the command design pattern).
Joined: Aug 17, 2005
Yeah, you're right. I need to take a step back, go back to the drawing board (not that I ever left it :-) and re-think my design.
I initially decided to use RMI, I was then considering changing that to use sockets to get the CP in there. I guess I've broken 'design rule' number one here.