This chapter is from the book
This chapter is from the book
This chapter is from the book
Summary
The MVC pattern reduces coupling within applications, but it also increases complexity in some cases. A clear separation of subsystems pays off in the long term by reducing maintenance costs and enabling incremental enhancements. The MVC design pattern serves you best if you think there might ever be a version 2.0 of the application you’re designing, and the larger the application, the more payoff MVC provides.
Another consideration is that it’s usually easier to test a Model directly rather than through a user interface. When testing through a user interface, extra effort is required to determine whether a test failure is the result of a bug in the core application logic or a bug in the user interface or both. Furthermore, the Model is often developed by one team and the user interfaces by another. The skills needed to develop the Model may be very different than those needed to produce an excellent user experience.
Even with all of the benefits of the MVC design, it’s not the best fit for every software project. At one extreme, a web application that runs on a server and displays information in a web page is the ideal candidate for the MVC design. There is already a clear separation between the View implemented by a web browser and the Model implemented on the server. At the other extreme are operating system device drivers and long-running computation-intensive programs. The application used to configure device drivers might adopt the MVC design, but the drivers themselves must conform to operating system interfaces and don’t usually present information directly to users. Long-running calculations are often batch processed and again don’t directly provide a user interface. In between the extremes, the combination of MVC and Cocoa proves valuable when applied to a wide range of applications including drawing programs, spreadsheets, games, word processors, and any sort of information viewer or editor.