• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Using the Front Controller Pattern for each architecture layer

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's more a command pattern than a controller.
 
Bob Lawson
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's impossible to answer that without knowing what kind of duplication you're trying to eliminate and so on.
 
Bob Lawson
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic