Is MVC a Design Pattern or Architectural pattern

Question

MVC is more of an architectural pattern, but not for complete application. MVC mostly relates to the UI / interaction layer of an application. You're still going to need business logic layer, maybe some service layer and data access layer. That is, if you're into n-tier approach.

Why does one of them have to be true?

Both can be true, depending on point of view.

MVC can be an architectual pattern, if it forms the basis of the application architecture.

It can also be seen as simply a design pattern, an abstract notion that is applicable to any application.

Design patterns say how to write code effectively (considering Code Metrics).

A few benefits:

1. Easily Maintainable
2. High Re-usability
3. Readable because of abstractions

Architectural patterns say how to utilize resources effectively.

1. Parallel tasks execution like programmers and graphic designers can work parallel.
2. Multiple technologies can be utilized to build a software.

In MVC, a). Views can be created using javascript templates and also html can be used b). Controllers can be written .NET framework and c). Models can be written in Java - a java service may be used that returns only json data.

While in design pattern, a pattern can't be implemented in which code can be written in multiple technologies like AdminUser class in Java, Customer class in C#, Partners class in Php and a factory pattern in Ruby :); hmmm..so easy?:)

I know that it's been answered awhile ago, but no one has yet mentioned the book that made MVC famous: Pattern-Oriented Software Architecture (POSA), by Buschmann, et al published in 1996. Though not as widely read as the Design Patterns book, by Gamma, et al, POSA is one of the foundational books used by the patterns community.

Oh, and POSA very clearly identifies MVC as an architectural pattern. My hunch is that MS and Sun are just being sloppy and calling every pattern a "design pattern".

The design patterns inside the Model/View/Controller (MVC) triad of classes include and may not be limited to:

• Observer, decoupling objects so that changes to one (the model) can affect any number of others (the views) without requiring the changed object (the model) to know details of the others (the views).

• Composite, which lets us treat a group object (a composite view) just like we treat one of its individual objects (view components).

• Strategy, where a view uses an instance of a Controller subclass to implement a particular response strategy; to implement a different strategy, simply replace the instance with a different kind of controller.

• Factory Method, specifying the default controller class for a view.

• Decorator, adding scrolling to a view.

---

Reference

• Pages 4 to 6 (Section 1.2 Design Patterns in Smalltalk MVC)
• Pages 293 to 304 (Observer design pattern)
• Pages 163 to 174 (Composite design pattern)
• Pages 315 to 324 (Strategy design pattern)
• Pages 107 to 116 (Factory Method design pattern)
• Pages 175 to 185 (Decorator design pattern)

Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1994.

I think both are true. If you're looking at a particular instantiation of MVC in a framework like Ruby on Rails, that instantiation is more of a design pattern. If you look at MVC as a general concept, it's more of an architectural pattern.

MVC always mentioned and introduced as/in presentation layer in software architecture books.

Read these books:

1. Architecting Microsoft.NET Solutions for the Enterprise (Microsoft press)

2. Professional ASP.NET design patterns (Wrox)

3. Enterpise Solutions Patterns Using Microsoft.NET (Microsoft press)

4. Patterns of Enterprise Application Architecture (Addison Wesley)

5. A Practical Guide to Enterprise Architecture (Prentice Hall)