Just my thought on this. I don't see any issue with what you have presented. Thinking in terms of your code what areas are likely to change?
Just an observation. Your "GetModule" function seems to be fragile as that may change because that is a "switch" statement. Abstract that away to a factory and your design will adhere to the "OCP (Open/Closed)" principle as you add functionality without modifying or breaking existing code.
Your use of Strategy pattern for BL can be justified because you are just trying to abstract away the algorithms (in this case business rules) that varies. But if your BL are an extension of existing business rules you can combine that with "decorator" as well.
"Others can comment as well".
Some other thoughts:
Menus and actions can be tied up using the "Command" pattern as well.
Rajesh Pillai, Jul 31, 2010
True. The other thing about the MVC pattern is that it promotes a convention, which in my humble opinion, is great! Learning to use Design Patterns correctly will, as Christian states, reduce the need for any particular presentation layer. Which is also a good thing. And by following some conventions, even some that you define yourself, will help make your application stronger, IMHO.
Aug 13, 2010
Funny thing is: The idea behind MVx is that it is easy to swap out any component if the overall design IS already following MVx. You say it was easy to swapp an ASP.NET UI to ASP.NET MVC UI. This is exactly what I expected to hear: If you have a more or less well designed application, you don't necessarily NEED an MVx design for easily replacing the view layer with another technology. This thesis reduces the advantage of a MVx approach (that is often underestimated in terms of necessary intial effort) to the second of the mostly acknowledged topics: Testability.
Jun 21, 2010