How do you design your application for different presentation layers?

Question

I am part of a team that is developing a web application using a proprietary mvc framework. This framework behaves a bit like a very poor man's struts! It has a central controller, configuration in properties file, torque like generated database action classes and no form beans.

Say you have a user account editing screen, Here is a typical piece of code that developers are writing: public class Handler extends StupidFrameworkBaseHandler{

// This is analogous to Struts Action
// Handlers are invoked by your controller.
    public void execute() {
     // get form elements
     }
    }
    }

To introduce the concept of form beans, an abstract getFormBean() method was declared extending the StupidFrameworkBaseHandler class. This method would be invoked by the BaseHandler class. So for now the code looks like this:

public class Handler extends ExtendedStupidFrameworkBaseHandler {

public void execute() {
UserEditFormBean bean = (UserEditFormBean) baseBean;
// business layer classes.
}

public BaseBean getFormBean() {
// get HTTP Request parameters and build an object.
UserEditFormBean bean = new UserEditFormBean();
bean.setUser(httpRequest.getParam("whatever"));
// other setters...
}
return bean;
}

In earlier applications that were developed using this framework, coders would code everything into the Handler - getting db connection, business logic etc. In order to change that the concept of business and DAO layer was introduced in my current application.

So final code looks a bit like this:

    public class Handler extends ExtendedStupidFrameworkBaseHandler {

    public void execute() {
     UserEditFormBean bean = (UserEditFormBean) baseBean;
     UserBO busObj = new UserBO();
     busObj.validateUserDetailsAndSave(bean); // I know this sucks..
    }

    public BaseBean getFormBean() {
     // grab user input from form and return a form bean instance.
    }

}

And the business layer looks like this:

   public UserBO extends BaseBO {

    public void validateUserDetailsAndSave(UserEditFormBean bean) {
    UserDAO dao = factory.getDao("user");
    // call getters on bean, do some validations, throw business exceptions.
    User objUser = new User();
    object.setUserName(bean.getUserName());
    // few more setters here on User -> that is the model.
    dao.update(objUser);
    }

    }

I find this overall design HORRIBLE, for many reasons:

1. UserBO is a class that has no state. It is just a set of methods with procedural code.
2. If you are calling these as layers, then each layer shouldn't depend on the other: UserBo would always expect one type of FormBean for each method and if I were to ignore HTML and re use the same BO class from a standalone java application, I would never be able to without creating FormBeans as params.
3. Code looks horrific and unmaintaineable.

So, my question here would be:

Shouldn't you develop a business layer independent of your presentation layer? I would rather code my business objects with proper state, validation and exception throwing?
Isn't the code provided as example above, really bad non-Java way of doing it?

Answer 1

Hi,

what I would suggest you is to take a look at the Spring Framework. It has a concept of IoC container (Inversion of control) and heavily relies on the dependency injection pattern. The latter pattern is extremely useful in decoupling your objects which is the major thing you have to assure when structuring your application layers. Your layers should be completely independent. So for instance your business layer should NEVER EVER reference things from your presentation layer. To assure that you can thing for instance of the following situation where you have the same business layer for a web presentation layer as well as for a standalone client application (presentation layer). If that's possible than you're on the right path.

To decouple your layers, you should always define clear "contracts" through according interfaces. So for instance you should have your business (or service) layer class MyService.java and an according IMyService.java (or MyServiceImpl.java and MyService.java as you prefer), where the IService.java is the interface defining the methods that are exposed by the actual implementation of the MyService class which basically contains your business logic. And so your presentation layer will just use the interface for connecting to your business layer. And here's where Spring comes into play with it's dependency injection. On your presentation layer you would have:

...
public void someMethod(..){
  IService service = new MyService();
  service.doSomething(...);
  ..
}

As you can see, this would again couple your layers by using the MyService() object. Therefore such instantiations are usually avoided and Factories are used to make it more independent (you already did something similar as I saw), such as defining it somewhere declaratively in a configuration file etc. Spring does this for you. I'm planning to write a post about these advantages of a layered architecture with Spring, however not before July since I'm currently quite busy.

Hope this gave you a rough idea on how it should be done.

Answer 2

You are right that you should keep your business and presentation layer separate.

I would second the recommendation of Spring Framework however given you are working with web applications I think you would be specifically interested in Spring Web MVC as this provides all the features you seem to be looking for.