CODEWITHSUNDEEP
javaservletsservice
markjason72
markjason72

Reputation: 1653

how to implement a service layer in servlet application

Suppose I want to create a service layer for my web application which uses servlets,How should I go about this?(I am not using a web app framework..So,please bear with me).Should I implement it as a listener?The service is meant to do database access.That is,I should be able to call from my servlet

class MyServlet{
...
    doPost(...){
    ...
        MyEntity entity = dbAccessService.getMyEntity(someId);
        ...
    }
}

Where the dbAccessService should deal with hibernate session,transactions etc.Previously I used to do all this inside dao methods, but I was advised that was not a good idea.

Any suggestions welcome

thanks

mark

Sample code snippet is given below

    class DBAccessServiceImpl{
    ...
        private MyEntity getMyEntity(Long id){
                Transaction tx = null;
                MyEntity me = null;
                Session session = HibernateUtil.getCurrentSession();
                try{
                    tx = session.beginTransaction();
                    return entitydao.findEntityById(id);
                }catch(RuntimeException e){
                    logger.info("problem occurred while calling findEntityById()");
                    throw e;
                }
            }
    ...
}

Then create a listener to instantiate DBAccessService

class MyAppListener implements ServletContextListener {

    @Override

    public void contextInitialized(ServletContextEvent ctxEvent) {

        ServletContext sc = ctxEvent.getServletContext();
        DBAccessService dbservice = new DBAccessServiceImpl();
        sc.setAttribute("dbAccessService",dbservice);

    }
}

In web.xml add listener

...
<listener>

    <listener-class>myapp.listeners.MyAppListener</listener-class>

 </listener>
...

Upvotes: 1

Views: 3634

Answers (2)

Tom Anderson
Tom Anderson

Reputation: 47163

What you're suggesting is really no different to doing the session and transaction handling in a DAO. After all, your service class calls the DAO; to the client code, there is no difference.

Rather, i suspect that whoever told you not to put the session handling in the DAO was thinking that you should instead use Open Session In View pattern. Very simply, in its usual form, that involves writing a Filter which opens a session and starts a transaction before passing the request down the chain, and then commits the transaction (or rolls it back if necessary) and closes the session after the request completes. That means that within any one request, all access to persistent objects happens in a single transaction and a single session, which is usually the right way to do it (it's certainly the fastest way to do it).

Upvotes: 2

home
home

Reputation: 12538

Assuming you do not want to introduce a framework, two options make sense (in my opinion):

  1. define your service layer using stateless EJB session beans. You need an EJB container.
  2. do it as always in OO languages, create an interface and a corresponding implementation:

Define an interface

public interface BusinessService {
    abstract public BusinessObject performSomeOperation(SomeInput input);
}

And an implementation

public class BusinessServiceImpl implements BusinessService {
    public BusinessObject performSomeOperation(SomeInput input) {
        // some logic here...
    }
}

You have several options for instantiating the service. If you start from scratch with a small application it may be sufficient to simply instantiate the service inside your web application:

BusinessService service = new BusinessServiceImpl();
service.performSomeOperation(...);

BTW: At a later time you may want to refactor and implement some abstractions around the Service instantiation (Factory pattern, dependency injection, etc.). Furthermore, in large systems there is a chance that you have to host the service layer on it's own infrastructure for scalability, so that your webapp communicates with the service layer via an open protocol, be it RESTful or Web Services.

However the future looks like, having a well defined interface defining your business functions in place, allows you to "easily" move forward if the application grows.

Response to your update: I would not implement the service itself as a listener, this does not make sense. Nevertheless, your sample code seems to be reasonable, but you must distinguish between the Service (in this case DBAccessService) and the way you instantiate/retrieve it (the listener). The listener you've implemented plays in fact the role of a ServiceLocator which is capable of finding a certain services. If you store the instance of your Service in the servlet context you have to remind that the service implementation must be thread safe.

You have to be carefull to not over-engineer your design - keep it simple as long as you cannot foresee further, complex requirements. If it's not yet complex I suggest to encapsulate the implementation using a simple static factory method:

public final class ServiceFactory {

    public static DBAccessService getDBAccessService() {
        DBAccessService service = new DBAccessServiceImpl();
        return service;
    }
}

Complex alternatives are available to implement the ServiceFactory and nowadays some call it anti-pattern. But as long as you do not want to start with dependency injection (etc.) this one is still a valid solution. The service implementation DBAccessServiceImpl is accessed at one place only (the factory). As I mentioned before - keep an eye on multi-threading... hope this helps!

Upvotes: 5

Related Questions