I am creating my first J2EE project, actually a "Hello World" project using J2EE technology, just to see if I got everything right. It�s a simple "piggybank" application, with simple operations like deposit, withdraw, transfer from one account to another, account management and clients(user) management. This is general architecture of the system:
should I a)create one servlet for each operation(WithdrawServlet, DepositServlet,...) or b) create one servlet for each group of operations that are similar(TransactionsServlet, AccountManagementServlet,...)?
if I choose option b), how does the servlet knows which operation to run? a big "if" statement?
Please help me out, if you know other solutions to this that you think is better than what I�ve said, please point it out and tell me why it is better. Any feedback is deeply appreciated. Francisco Areas Guimaraes [ October 11, 2002: Message edited by: Francisco A Guimaraes ] [ October 11, 2002: Message edited by: Francisco A Guimaraes ]
Francisco<br />SCJP<br />please use the [code][/code] tags when showing code.Click <a href="http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=ubb_code_page" target="_blank" rel="nofollow">here</a> to see an example.
I would recommend checking out the struts framework from apache. They provide a good MVC framework for doing stuff like this) Here is one way of doing it (stealing the idea from struts, but its general MVC i think):
The XXXHandlers could implement a TransactionHandler interface. Delegate would be responsible with communicating with the enterprise layer. Session beans would wrap you domain classes. Your domain classes would do the actual processing of the transaction. The transaction would be recorded using EntityBeans. They way you would tell the difference between the requests is by making the form actions different (ex: withdrawal.do, deposit.do), map the controller servlet to *.do, now the servlet should be able to figure out what kind of request it is. In real-life I would just have the XXXHandlers interact with the domain classes without the EJBs. Question: Is this what is reffered to as "over engeneering" or is this not even good enough to call it that? [ October 11, 2002: Message edited by: Steve Chernyak ] [ October 11, 2002: Message edited by: Steve Chernyak ]
Steve's right, take a look at something like Struts for an idea of how you can partition your server-side, controller functionality. Also, if you're looking for some more detail about this (i.e. how it works behind the scenes, alternatives, etc) then take a look at Designing Web Applications and Servlet Patterns that is available to download for free in (printable) PDF format. Regards Simon [ October 14, 2002: Message edited by: Simon Brown ]
Francisco, It sounds like you are already on the right track. They are both right about Struts. It provides a nice front controller and there is a lot of community activity wrt to Struts. The problem you will face (getting started) is good documentation. I suggest getting Mastering Struts from Wiley (and Struts from Orielly) to help you bridge the gap. Struts does have a learning curve. Sun also has a list of design patterns for J2EE. The one you are probably interested in based on your post is as follows: Front Controller (Servlet) There are several good free Struts tutorials that will help you get started. Here is one of them.... Struts Tutorial Here are a list of tutorials for Struts List of Tutorials None of this existed when we were learning Struts at eBlox. I also wrote a tutorial on Struts for the book Mastering Tomcat. I also teach a J2EE/Struts course. If you need something quick, I suggest using the front controller pattern. If you have some time to devote to learning a new and useful framework, I suggest using Struts.
Thanks everybody for the great feedback. I definitely have heard of struts and I know it�s great, but it would be too much for my little piggybank, bu trest assured I will look into it in a near future. I�ll look at the patterns and see what I�ll do.Thanks agian for the marvelous response. Francisco Areas Guimaraes