Servlets with Database design

I have a general question about using Servlet and JDBC.

For instance, I have a class called MyDatabaseManager, which provides functions

public boolean updateUser(User user) {...}
public boolean deleteUser(User user) {...}
public boolean inserUser(Us开发者_StackOverflower user){...}

, these functions will access and manipulate the Database.

My question is on the Servlet implementation. I am using three Servlets (UpdateUserServlet,InsertUserServlet and DeleteUserServlet) at the moment and each Servlet calls the MyDatabaseManager instance (only one instance here, using Singleton pattern) function. (For example, UpdateUserServlet calls MyDatabaseManager.updateUser ...).

I think this is the most straightforward way of using Servlet and Database. But I am not sure if this is the correct way of doing it. For example, how is this implemented in the industry world.

People don't really use servlets directly nowadays, they use frameworks that allow you to simplify your work, but if you really want to use servlets, you can make all actions in a single one, using the other methods, doPut, doDelete and even creating your own methods. Here's a sample of how you would do it:

public abstract class BaseServlet extends HttpServlet {

    @Override
    protected void service(HttpServletRequest request,
        HttpServletResponse response) throws ServletException, IOException {
        String method = request.getParameter("_method");
        if ("form".equals(method)) {
            this.doForm(request, response);
        } else {
            if ("delete".equals(method)) {
                this.doDelete(request, response);
            } else {
        super.service(request, response);
            }
        }
   }

   protected void doForm(HttpServletRequest request,
        HttpServletResponse response) throws ServletException, IOException {
        throw new UnsupportedOperationException();
   }

}

As you can see, this Servlet uses a special field _method on forms to decide what special method to call, if the _method is not available it's going to use the usual service method and is going to call doGet or doPost.

And here's how an implementation for this servlet would look like:

public class UsersServlet extends BaseServlet {

private UsersRepository cadastro = new UsersRepository();

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException {

    req.setAttribute("usuarios", cadastro.list());
    req.getRequestDispatcher("/usuarios/listar.jsp").forward(req, resp);

}

@Override
protected void doPost(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException {

    User usuario = this.getUser(req);

    usuario.setNome(req.getParameter("nome"));
    usuario.setEmail(req.getParameter("email"));
    usuario.setSenha(req.getParameter("senha"));

    this.cadastro.persist(usuario);

    resp.sendRedirect(req.getContextPath() + "/usuarios");

}

protected User getUser(HttpServletRequest req) {
    User usuario;

    if (req.getParameter("id") == null) {
        usuario = new Usuario();
    } else {
        Long id = new Long(req.getParameter("id"));
        usuario = this.cadastro.search(id);
    }

    return usuario;
}

@Override
protected void doDelete(HttpServletRequest req, HttpServletResponse resp)
        throws ServletException, IOException {
    User usuario = this.getUser(req);
    this.cadastro.remover(usuario);
    resp.sendRedirect(req.getContextPath() + "/usuarios");
}

@Override
protected void doForm(HttpServletRequest request,
        HttpServletResponse response) throws ServletException, IOException {

    User usuario = this.getUser(request);

    request.setAttribute("usuario", usuario);
    request.getRequestDispatcher("/usuarios/form.jsp").forward(request,
            response);
}

}

This way you can make it all in a single servlet.

Difficult to answer because there are hundreds of design patterns out there! I know a good one about Database management is called DAO (data access objects). I use this one a lot. I advice you to take a look.

Don't get me wrong, a Singleton to hold your Manager is a good idea. Pretty much that's what I usually do too. However, usually I have a DAOFactorySingleton which pretty much have the responsibility to generate all classes DAO in my app and this factory is good because I can have some DataSource rules that this factory just poll from somewhere and inject in my DAO! So, pretty much, each DAO doesn't have to care about things like JDBC connection!

Follow 2 links to explain more about DAO! http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

http://community.jboss.org/wiki/GenericDataAccessObjects

The second one is to use with hibernate! you can read it and is not mandatory using just with hibernate. I really like that second one, more complex though.

This is surely a matter of design choice, you can adopt a framework like Spring, Struts etc.. which make this much easier. Alternatively if you want to use the classic servlet request/response pattern, I will suggest creating a parent servlet which intercepts request and passes it on to the right method to perform the request.

Additionally you have a choice to various ORM solutions like Hibernate, JPA etc.. which you can use to handle your database access operations. Yet if you choose to stick to the classic JDBC calls, you can use Filters and Handlers to decide which calls to provide wrap database connection and operation against.

Singleton on the Database class sounds good, especially as it seems to contain update/delete/insert code.

If you're using Connection Pools, make sure you Singleton the DataSourceFactory.

Many in the industry use ORM + Dependency Injection framework + transaction manager + database pooling libraries, for example Hibernate (ORM) + Spring DI (Dependency Injection) + Spring transaction manager (transaction manager) + Apache DBCP (DB connection pooling).

Sometimes when the use of ORM cannot be justified (e.g. very simple DB schema, ORM performance overhead is prohibitive due to the nature of the app. etc.), developers might use raw JDBC. Many would still use dependency injection and DB connection pooling.

It is very rare that the use of dependency injection or DB connection pooling cannot be justified. I.e., unless it is a very rare, special app., developers in the industry do use dependency injection framework and DB connection pooling.

In this case the state that needs to be managed is managed by the DB connection pooling framework, so you should not have to worry about state management or thread safety (as long as you don't share anything between different threads yourself and follow the API of the DB connection pool framework). I.e., you won't need a singleton. If you implement your own DB connection pool, then using a singleton would make sense.

If a developer doesn't want to use any framework (e.g. creating a very simple tool), then many would just open a connection every time (for each thread). In this case, you again don't need to manage any state so you won't need a singleton.

In the industry world, we are all for simplicity. For example, for user interaction from browser, to server, to a persistence storage (database), we follow these approaches.

An MVC pattern, first and foremost. This would allow us to totally not write a Servlet for each user interaction from browser to server. What this allows us to do is to do the following:

• Allow the controller to handle user request and link it to our user action (our model). This model allows us to write business logic to respond to user data.

In today's Java World, Frameworks exists that meets our MVC requirements. The one that comes out the Java box is JSF (JavaServer Faces).

For backend, we definitely use databases, but we are clever too and use ORM (Object Relational Mapping) to model our real-world problem into an Object model and how to best persist (store) these object models. Some usesERM (Entity-Relational Modelling) to design a semantic data model.

In the middle, the business logic, we add a service (as the business logic layer) doesn't want to care about where to read/write data, as long as they can see the data it wants. For this, a Service layer is added that facilitates this. In essence we have this effect.

public class ActionServlet extends HttpServlet {
    
    //Action registration
    public void init() {
        ActionMapping mapping = .....; //some instatiation
        mapping.setAction("/userRegistration", UserRegistrationAction.class);
        
        //Save it in Application Scope
        getServletContext().setAttribute("actionConfig", mapping);
    }
    
    private void doAction(HttpServletRequest request, HttpServletResponse response) throws Exception {
        String path = request.getPathInfo();
        
        Action action = ((ActionMapping)getServletContext().getAttribute("actionConfig")).getAction(path);
        if (action == null) {
            throw new Exception("No action of '" + path + "' found.");
        }
        
        action.execute(request, response);
    }
    
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws Exception {
        doAction(request, response);
    }
    
    public void doPost(HttpServletRequest request, HttpServletResponse response) throws Exception {
        doAction(request, response);
    }
}


public abstract class Action {
    
    public abstract void execute(HttpServletRequest request, HttpServletResponse response) throws Exception;
    
    protected void dispatch(HttpServletRequest request, String path) {
        
        RequestDispatcher dispatcher = request.getRequestDispatcher(path);
        dispatcher.forward(request, response);
    }
}


public class UserRegistrationAction extends Action {
    
    public void execute(HttpServletRequest request, HttpServletResponse response) throws Exception {
        //Business Logic goes here...
        //Call DAO,
        UserRegistrationDAO dao = ; //Some DAO instantation
        User user = createUserFromForm(request);
        dao.save(user);
        
        dispatch(request, "success");
    }
}

As for persistence, Java 5 & higher comes with JPA. You can use any form of ORM that you want, depending on your project scope. There's Hibernate (which also supports JPA) or if you want to, write your own DAO.

One more thing, all these processes are tedious to glue together. Fortunately, we have frameworks that helps us make our beautiful example above much easier. Frameworks like JBoss Seam does this and it fully uses Java specifications. For now, go for the simple design models and MVC (for learning purposes). As you get accustomed to the architecture, use frameworks.