Monday, April 26, 2010
Modular Design vs. MVC
Usually the implementation of the View in MVC is something that is so geared towards presentation or the final display of the data that reuse by other components (those not interested in the presentation, but only interested in the data produced for the presentation) are not considered. Think of just about any standard framework used to help implement the view for a web application in any programming language. Do you have an easy way to just call that code from the controller and get its response for reuse somewhere else in the application? Probably not. So, why would you want to? In an Rails app + XML/JSON/JSONP service that we had developed, the first version of the app/service did the XML/JSON/JSONP generation outside of the view code. For example, the to_xml implementation was just another method, so it would have been simple enough to reuse it almost anywhere within the app. However, in the second version of the app/service, this was changed so that there was a view to generate the XML. Considering XML to be a view just like anything else seems at first to a good idea. But it makes it more complex now to do the equivalent of to_xml if you need it elsewhere in the app. This seems to have somewhat sacrificed Modular Design for the traditional push of presentation-related code into the view layer. MVC would at first appear just to be a subset of Modular Design. But the problem is that when you say (just as an example), "This functionality is just for the view, so I don't really care if you want to use it for anything else, because my job is just to provide the last step prior to presentation," you are probably sacrificing some degree of modularity and potential reuse. For webapps, there are obvious benefits for using MVC, and odds are the framework you are using promotes MVC. However, it makes sense to at least consider Modular Design principles when coding bits of functionality that could be reused.