I am currently investigating the possibility to incorporate MVC into our existing WebForms framework. Currently we have the notion of "modules" like ThreadsModules and CreateMessageModule. The modules are just UserControls that are being loaded onto a page by the framework. On postback the ASP.NET WebForms parses the _EVENTTARGET and _EVENTARGUMENT fields and raises the appropriate event handlers (just like any other webforms page works).
In MVC, however, there are no controls and there is no postb开发者_开发百科ack. So the question is what's there? Everywhere the notion of Model-View-Controller talks about a particular page, but I need modules. So I was thinking of making the modules consist of model-partial view-controller and creating a MasterController that will parse the request and call the appropriate module's controller.
However with this approach there is still the problem of integrating different controllers into one page. For example on a page I have the ThreadsModule which contains a grid. The grid needs to sort and page so it needs its own controller. So right there I will have 2 nesting forms which both will submit whenever I click on "Sort" button in the grid. Obviously I could make the ThreadsModule controller deal with the grid's sorting. But this means I will have to make every other module that has grids to know how to sort. A lot of redundancy and inefficiency.
Basically the main question is how to encapsulate complex logic that can be reused across controllers?
UPD: Let me give another scenario. You have a page with multiple forms on it. The forms post to different targets, possibly on different controllers. In what way could the user stay on the same page, after any particular form submits its request? Again, it is useful for encapsulating and reusing logic.
It sounds to me like you're trying to shoehorn concepts created to address the specific requirements of WebForms into MVC.
I would suggest that you do NOT try to apply WebForms architecture to MVC. It's really its own philosophy and way of doing things. Just because something worked well in WebForms doesn't mean it has to work the same way in MVC.
Your architecture sounds like it's poorly designed, and puts a lot of business logic in user controls. This is not the way to do things in MVC. Instead, you should refactor those controls into "services" that your controllers can call.
EDIT:
It's important to remember that MVC is a presentation architecture, not an overall application architecture. MVC only concerns itself with how to present information to the user, and how to capture their input. All business rules, calculations, logic, should happen in business objects that have nothing to do with controllers, or views.. and only vaguely associated with models.
You have complete control over the rendedered output. If you want to use multiple forms, with different targets, you can do so. Just set your action to whatever you want.
精彩评论