File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Using the Front Controller Pattern for each architecture layer Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Using the Front Controller Pattern for each architecture layer" Watch "Using the Front Controller Pattern for each architecture layer" New topic
Author

Using the Front Controller Pattern for each architecture layer

Bob Lawson
Ranch Hand

Joined: Jul 20, 2010
Posts: 34
The traditional use of the front controllern patter seems to be at the servlet level. The web handler gets requests from the web server and calls the command matching the request (Fowler, PEAA). But I am wondering if it makes sense to apply this pattern at each architecture layer, i.e., the service layer, application layer, DAO layer, etc. Our service layer is responsible for providing an api to clients, performing transaction control, and calling the application layer. The application layer is responsible for use-case logic. It performs tasks such as authorization, validation, calling DAOs for retrieval of domain objects, calling and co-ordinating domain objects, notifications, auditing, logging, etc. The DAO layer is responsible for retrieval and storage of data. I am considering refactorings for a project that has already been developed, but the code is very complicated and redundant, difficult to test and maintain. I've noticed that many class methods within any given layer has a lot of behavior in common with other methods in that layer, with only minor variations. This behavior could be abstracted to the handler, which could then call commands for behavior particular to a request. So it makes sense that each layer has a handler has template behavior and is injected with a hashmap of commands keyed by request type. For this approach to work, however, the paramters passed to each layer would have to be placed in a request object rather than being part of the method signature. This is so the various commands can all implement the same interface.

Please share your thoughts on this idea. Has anyone out there ever done something similar?
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

That's more a command pattern than a controller.
Bob Lawson
Ranch Hand

Joined: Jul 20, 2010
Posts: 34
But isn't the command pattern part of the front controller pattern? But regardless of what pattern it is, I'm really interested in knowing if some of you experiened designers/architects have implemented anything like this. Is it over-engineering? Is there a better way?
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

One purpose of the command pattern is to abstract implementations. With dependency injection so prevalent I'm not sure I'd bother, especially if the only usage of the command names are internal to your code.

It's also possible I just don't understand enough about what you're trying to accomplish and/pr why.
Bob Lawson
Ranch Hand

Joined: Jul 20, 2010
Posts: 34
With dependency injection so prevalent I'm not sure I'd bother


By this, do you mean that this pattern uses a lot of DI and so it might not be worth the trouble?

What I am trying to accomplish is getting rid of the enormous amounts of duplication in each of the service layer methods, application layer methods and DAO layer methods. A key goal of Front Controller, at least accoring to Fowler, is to "consolidate all request handling by channeling the requests through a single handler object. This object can carry out common behavior, which can be modified at runtime with decorators. The handler then dispatches to command objects for behavior particular to a request". I am just asking if it makes sense to apply this pattern not only to the servlet layer, but to each architecture layer beyond the servlet layer (Service, Application, DAO), because just like the servlet layer, those layers handle many requests, and if there is seperate code for each request, the result is code duplication. So I am just looking for the best way to address duplication in each of these layers.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

It's impossible to answer that without knowing what kind of duplication you're trying to eliminate and so on.
Bob Lawson
Ranch Hand

Joined: Jul 20, 2010
Posts: 34
I mentioned those things in my original post. Things like transaction control in the service layer, authorization, validation, calling DAOs for retrieval of domain objects, notifications, auditing in the application layer. And within the DAO layer, there is a lot of boiler plate code for retrievals that can be abstracted to a higher level.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Sounds like a simple base class with specific functionality implemented in subclasses; how to get to the specific implementation doesn't really matter--DI, command pattern, whatever.
Bob Lawson
Ranch Hand

Joined: Jul 20, 2010
Posts: 34
Yes, but here is the difference: For example, a traditional DAO has many methods - often times lots of retrieval methods. These methods often are doing essentially the same thing, with minor variations. I can't create a base class to abstract out the common behavior, unless I use the base class as kind of a helper class that the subs call. I don't want to do that because it would create too tight of a coupling between the subs and the base. I prefer an IOC approach (GoF template method pattern), where the base implements an abstract retrieval method and calls the sub for specific behavior. But to do this, I would need to create multiple objects, one for each DAO method. Each one of those objects could be a command object that could be invoked by the client based on some request type (e.g., FindById, FindByName, FindBySSNum, etc).

So my point is, to have a base class and use it in a way that supports IOC, it seems to point towards turning each method into its own object and invoke it using something like the command pattern, front controller, etc.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

At this point I don't understand what you're asking anymore--you've stated the problem, given a solution. What's left?
Bob Lawson
Ranch Hand

Joined: Jul 20, 2010
Posts: 34
Just wanted to know if folks thought the solution is a good one, if its over-engineering, if there a better way to handle this, etc. Sorry, I didn't mean for it to get so confusing. Thanks for your time.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

If there's large chunks of duplicate functionality, and those chunks would all need to change if the requirements changed, then it should be refactored--assuming the ROI is worth it, or you're just bored and want to make something nice. My only concern would be to try to not reinvent the wheel if an existing solution would work and save effort.
Bob Lawson
Ranch Hand

Joined: Jul 20, 2010
Posts: 34
Oh, I'm definitely bored (we have been in O&M for too long now), but the customer has asked us to do some refactoring to get rid of bad smells.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Using the Front Controller Pattern for each architecture layer
 
Similar Threads
Placing interfaces and respective implementations in seperate packages
SCBCD still relevant and worthwhile?
Use of DAO as a Command?
Understanding a DAO v Service seperation...
How to pass an object between MVC controllers?