Is MVC at odds with Agile?

Question

Agile emphasizes quick iterations without wasteful planning.

MVC emphasizes separation of concerns based on a planned architecture.

Since non-MVC technologies require less planning, could they be more appropriate in an Agile project?

Answer 1

Separation of concerns does not necessitate that you plan out every detail before you start coding. And agile does not mean that you just write the code down as it comes to mind. Agile means not being too attached to your initial idea of what the project will look like and to be ready to refactor should the need arise (as it usually does), not being afraid to throw big pieces of code out in the process.

Separation of concerns can very well make refactoring a lot easier, so MVC can be a big helper of agility.

Answer 2

When you find the right balance between structure and flexibility, it's worth its weight in gold.

I tend not to like most (current) MVC paradigms, because I believe they introduce pointless abstraction, reinvent the wheel, and add a lot of rigidity.

But I also tend to have highly structured programs that separate content from business logic from data access, and have as few "configurations" as possible in order to accomplish 1 thing. Ideally, to accomplish 1 thing, you should only have to edit 1-2 things.

Needless abstraction is the root of many problems.

Answer 3

Design patterns are a fundamental part of quick development. Popular design patterns are popular because they have wide utility. Relying heavily on patterns can make a workable architecture for a project crystallize much more quickly. The common vocabulary afforded by design patterns make it easier for a team to communicate the structures of a project and focus on the domain specific issues. Should one pattern turn out to be inconvenient for the progress of the project, the relation ship that pattern has with other alternatives are likely well understood, simplifying the task of refactoring to an alternative layout.

That being said, the MVC pattern has tremendous gravity. One of the major reasons it works so well is that it tends to emphasize API's. This sort of isolation makes it much easier to change certain parts of a system without having a major effect on unrelated parts. If a layer of the system has a defect, it's normally easy to alter that layer without affecting other layers, because they are separated by a well defined API. If an API is itself deficient, then it is often possible to alter the API exposed without effecting the actual logic of either layer (Although this tends to be more difficult than the first kind of deficiency).

Answer 4

The key phrase in agile is 'the simplest thing that could possibly work'.

If the simplest solution to a problem is:

• a single script
• a single web page
• a single installation of a standard tool like a wiki
• a single-user single-database 'just edit the data' editor

Then those won't have MVC, and will be the appropriate agile solutions.

If it is obvious from the start of the project that nothing like that is going to come close to solving the problem, it would be pointlessly literal process-following to try them and wait to fail before trying the next simplest solution.

Answer 5

Agile development is typically a process of rapid prototyping and refactoring. MVC's separation of concerns can often make both processes easier and faster.