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?