This is only about the third servlet I've written, so I'm looking for feedback in order to improve the next one. In particular I'm wondering about the connection process. The init() method looks up the jndi name so it only happens once. When the DAO is created, the servlet gets the connection and passes it to the DAO constructor. The DAO closes the resultset, the prepared statement, and the connection. Is this a sound design or is there a better way to do this?
I know that one thing I need to do is implement log4j and log the exceptions instead of just doing a printStackTrace(). That will be on the next project.
Any feedback is welcome; it's the only way I'll get better at this. (btw, the package declaration and imports are removed so as not to give away where I work. Someone higher up might frown on that)
"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do." -- Ted Nelson
Dieter Quickfend wrote:Your collections should be generic by now. for lookups, just use Service Locator or Dependency Injection...
Also, you should read up on the MVC (Model View Controller) design pattern. Your servlet should be limited to control logic between the model (beans) and the view (JSP)
Any particular reason why you get your connection and such in the servlet?
Such as List<String> goalsList = new ArrayList<String>() ? Thanks for the tip; I'll make that change. Please explain more about the lookups. Are you referring to the JNDI lookup? I'll google Service Locator. I though Dependency Injection was a Spring feature. Can you recommend a resource where I can learn more about that?
I thought this was a halfway-decent MVC design (so much to learn). What logic am I doing that doesn't belong in the servlet? I'm guessing that you are referring to the connection stuff. That's just based on examples that I saw. Should that be delegated to the DAO?
Spring is a dependency injection container (well, part of it is), but it's not alone in that. CDI(Contexts and Dependency Injection) is a standard now, and the reference implementation is JBoss Weld. Depends on what container you're using though, probably not java 6, but still, there are ways. Service Locator is another good way so you don't have to work with JNDI lookups in all your servlets.
Don't confuse your model with your DAO layer. A model is much more than that. What you address from your servlet should be your business layer. Hence you can call various DAO methods from one business method, and return a view-ready list to your controller because your business method can be more coarse-grained than your DAO method.
I found that my HFSJ book covers service locator in chapter 14 (I'm only up to chapter 10) so I'll tackle it from that direction.
As for MVC, are you saying that the servlet shouldn't instantiate the DAO at all, but instead delegate that to a POJO that acts as the model layer? Should the DAO send results back to the servlet directly, or pass them to a class in the model layer and let it communicate with the servlet? That would prevent the servlet from even having to know about the DAO...hmmm
what you need here is what is called a separation of concerns. you have to isolate your components from each other which will make your design more flexible in case of change for example.
your servlet doesn't have to instantiate your daos. It more likely have to be done in another "class" representing your business process.
also it seems combersome for the servlet to open connections, open and close resultsets and so on, these operation have to be done in another Pojo which is responsible for them. Think of the single responsibility principle.
and as mentionned above, clearly you have to use a serviceLocator for JNDI.