Chapter 7. Scaling the architecture for complex sites
This chapter covers
- Taming large controller actions
- Leveraging view helpers
- Using partials
- Creating components
- Applying action filters
- Organizing controllers into areas
Most applications we write grow beyond their originally intended use. Often we see quick-and-dirty, low-quality demos graduate directly to production. These applications have to be maintained, and likely by you (or me). Complexity is inevitable, but we can follow good design principles to keep the applications maintainable.
How can we ensure that we are creating maintainable solutions in the face of complexity? One key principle to follow is the single responsibility principle (SRP). This principle states that a piece of code should only have one reason to change. In this chapter we will visit some of the areas that often grow out of control in sites of any measurable size. The first is controller actions.
We’re all guilty of it. Given a place to put our code, we do just that: put code in a file. And it grows. And grows. Pretty soon we’re staring at single methods that span the entire viewable region. For starters, we should be able to read the entire action on a single screen. No, I don’t mean wrap the offending code in a #region block and hide it. (Yes, your authors have seen this too). We need to identify the areas that belong in other classes and extract them.