Controller Servlet

Question

Hello,
I'm developing web framework.
Framework architecture is the following:
Controller servlet(C) as a gate to JSP in /WEB-INF, so all requests are mado through this servlet.
If request points to simple static JSP page C is doing it's job, but when I need to prepopulate JSP
with POJO value objects I need to make modifications to C code.
C methods grow as application functionality grows and it will be fat soon.
How can I refactor C to make somekind of WebAction to prepopulate JSP not storing Business Logic in
this servlet ?
Thanks in advnce.

Answer 1

I can sympathise with that but consider:
I've broken some long-winded processing down into a
number of smaller methods called from a bounding
"doSomeProcess" method. Either each of these methods
gets a new connection and releases it, in which case
transaction handling becomes an issue or each of the
component methods needs to take the existing DB
Connection as an argument.
The former opens a can of worms and could introduce
well obscured bugs while the later achieves much the
same as my getConnection -> handler.process
->releaseConnection model but by passing the
connection down the line.I prefer the second approach. It keeps one connection open as long as it needs to be, and makes sure it closes as soon as possible. I don't see what making it a member of the class saves, except the passing of a parameter.
Not quite. If the controller gets and releases the
connection, it can be passed into a constructor or set
through an accessor method. The handler itself then
doesn't need to get or release anything. As everything
is going through the controller the connection will
always be tidied away. And with the connection pool
counting the number of times that connection has been
used, we can be confident that it will be destroyed
when its time is up.Okay, that's an approach. but that couples the Controller/Web Application to the Database. I try to keep the data layer separate from the controll layer. My approach is to create a Data Access Interface and code my handlers (and Control Servlet usually won't use it, that is the handler's job) against that. I then set an environmental entry that specifies the concreate implementation of the interface. This means the Handler does not need to change based on what data structure is used in the Underlying Data Access Object.
The immediate benefit is that during early stages orf development, I can create a simple wrapper around a java.util.List when testing my web application and developing an interface to use. Then code my real Data Model to this interface and independently of the web application. When I am sure that both are working correctly independently, I can put them together by changing the environment entry, and nothing else.
This also means that if I want to change how I store my data from a database to XML, or to a feed from an external site, or a resource bundle, or whatever, I can do so without changing my Handlers/Controller, but just by coding a new Data Access Object and fixing the environment entry.
(alternative to the environment entry my be a context parameter that my controller will read, create the class, and pass to handlers, but I still think this is bad since it widens the scope of the DAO)
This was my initial response to building web apps,
probably because of my (long forgotten) ASP
background. However, each method within the handling
process can be made much cleaner and simpler when we
don't need to worry about db connections (getting,
releasing or otherwise handling).But in reality, you are not getting rid of it. You are just moving it further away from where it is used, thus expanding its scope and increasing the possibility for errors. (That is my view anyway...)
If you have time I'd recommend looking into this. I
can't take all the credit for it but I am a staunch
evangelist for the architecture. I guess it's because
I'm lazy and like the idea of all the crunchy bits
being hidden away in superclasses that I don't need to
play with.I am all for a good inheritance pattern, but I am also one for keeping objects in the smallest scope, and as close to their usage as possible. having a method in an abstract super class that closes connections might be usefull, but this would have to (in my book) be part of the Data Access Object's inheritance tree and not part of the Handler's/Controller's. ie: i might have
abstract class SQLDataAccess
with a method called
protected Connection getConnection(...)
that will take a connection from the naming context, initialize it, and return it, and another named
protected void closeConnection(Connection ...)
that will go through the process of closing the DB connection. And then, I might have a method called public List getEmployeeList()
  Connection connection = getConnection(...);
  List empList = null;
  try
    empList = getEmployees(connection);
  } catch (...)
  finally
    closeConnection(connection);
    return empList;
}or some such...
Then have the abstract method
abstract List getEmployees(Connection ...) throws ...;
that the sub classes might need to implement on a DB specific or case specific manner. But this type of thing would all be in the DataAccessObject heirarchy, and the need for DB connections would never leak out from that into the controller or handler.