There are cases when your code base grows and the functionality and purpose of your business services and components needs to extend beyond what they were originally intended for, and just MVC may not be enough.

In this post I will try to show an extension of the MVC pattern meant to scale up and provide more separation of concerns in an enterprise system that might be composed of multiple layers / applications / components.

Here is an example of how a request can be service in a multi tier environment following a MVC like pattern with a couple of extra layers…

VIEW: A UI client, website, mobile, or any other requester launches a request against the app. All View Managers are exposed as web services / rest interfaces to the outside world.
VIEW: The View manager receives some data transfer object for a given operation.
CONTROLLER: The View manager delegates the data to the appropriate business service.
CONTROLLER / SERVICE: The transaction starts, the business service applies the application logic to the current request.
MODEL : The business service delegates state change in domain objects to the appropriate model manager.
MODEL : The model manager performs state change and acts as factory for domain objects if necessary.
MODEL : If the domain objects is persistent the model manager delegates persistence operations to the appropriate persistence adapter.
PERSISTENCE : The persistence adapter is specific to the technology that is being used to persist the objects, ej: database, LDAP…
MODEL: The Model manager receives Persistent Objects that may in fact be domain objects like in a hibernate based implementation.
MODEL : The model returns the domain objects to the business service.
CONTROLLER / SERVICE: The business service applies the application logic to the returned domain objects if necessary.
VIEW: The transaction ends, The View manager receives some data back from the business service as a read only facade, impeding further modification of the state.
VIEW : The view manager turns the read-only data into the appropriate view objects that are served back to the client.

And the question is… Why a couple of extra layers, can I just do all that in the controller?

In my opinion this type of architecture allows you to….

1. Scale up any layer as needed since the DTOs between layers are Serializable and you can actually partition the layers and place load balancers in between and deploy layers in different servers by converting each service layer in web services.
2. Since each service on each layer is based on an interface implementation you can deploy different view, business and persistence strategies for different clients and the same application or vice-versa.
3. Layers can be reused in different applications with different business logic.
4. All operations in your application are agnostic to the persistence mechanism used.
5. Method bodies are smaller and all parts in your app are very well structured which help you to easily navigate code without getting lost in 1000+ line methods.

The bad part is…

1. It takes you to build a couple of operations to realize that it is actually easier this way than writing long methods that do everything from constructing your objects to connect to the database and applying the right business rules.
2. Some devs think less files is better.

No, seriously, this is a pattern that I personally like for most projects but I understand in can be overkill for small things.
If you have any comments or know a better way, I’d love to hear your opinion.

An example of this pattern implemented with Java + Spring is available for download at…

svn checkout http://raulrajatutorials.googlecode.com/svn/trunk/ raulrajatutorials-read-only

Comments in the code itself should be self-explanatory if you already have some java + spring experience.

In the following pages you can see actually log output that demonstrate how the request travels through the layers and how exception handling at the view level intercepts any Throwable and turns it into the right View Object.

Pages: 1 2

This post is tagged Architecture, Java, MVC, Patterns