Gerry Scheetz wrote: > Start off with Hans I loved the book. It was extremely helpful when I > was first writing JSP/Servlet applications. Great job!
Thanks, I'm glad you liked it. > [...] >>The variation of the above that I had in mind goes something like >>this. Let your Access classes use another set of classes to access >>the database. These classes encapsulate all SQL code and can return >>the data as beans that you pass on to the JSP pages. A simple example: > > I like this a lot, I just have a couple questions/clarifications. > > First, say I have the need to retrieve and employee from the database and > then update the information about that employee. Would I create two > Access classes (GetEmp and UpdateEmp) or would I, should I, could I > create just one Access class (EmpRepository). Also are the Access > classes singleton classes? Since you have my book, I suggest you read Chapter 14, "Combining Servlets and JSP", and Chapter 17, "Developing Database Access Components." I answer these questions in detail there. You can also take a look at Struts for some ideas. But here are some brief answers. Each Action class should correspond to one request type, so if you support retrieving data with one request and update with another, you should have two Access classes. If you have one request type that combines multiple database operations, say update information and then retrieves the updated info, you should have one Access class for both operations. Again Action classes correspond one-to-one with request types. The data access classes (DAO) does not have this relationship to requests, though. You may, for instance, have one DAO class that deals with all employee information operations, and another that deals with all product operations. These classes can be shared by multiple Access classes. Regarding singleton classes, it's up to you. In general, it's a good idea to only keep one instance of Action and DAO classes around (to minimize memory needs), and typically these types of classes are easy to make threadsafe, since they only need read access to instance variables (e.g. the pool) and get all info they needed to process one request as method arguments. Strictly, a singleton is a class with a static getInstance() method, but another way to accomplish the same goal is to keep a HashMap with instances. If the HashMap is stored as a ServletContext attribute, the DAO classes can get to it easily. > [...] > Are you assuming the data source is retrieved from a JNDI lookup or > returned from a singleton class or do I actually create a separate > connection pool for each access class. I left that as an exercise for you ;-) In a container that supports JNDI, getting it from JNDI is the best way. But if that's not an option (many servlet containers don't support JNDI), the controller servlet (or an application life cycle event listener in Servlet 2.3) can create the pool and make it available to the rest of the application as a ServletContext attribute. I describe this in more detail in Chapter 17. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com JavaServer Pages http://TheJSPBook.com =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST". Some relevant FAQs on JSP/Servlets can be found at: http://archives.java.sun.com/jsp-interest.html http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.jsp http://www.jguru.com/faq/index.jsp http://www.jspinsider.com
