MVC - design pattern or framework?
Hi!
In 50% of the websites I've found they count MVC as a design pattern, in the other 50% they count it as a framework...What is your opinion about it?
Since design patterns describe "solutions" on recurring problems without making it code specific, meaning different implementations could make the same result this would in my meaning count as a pattern while a framework would take into consideration which language you are using aswell as stuff like (Swing for representing the view etc)
And MVC isn't listed in the GoF book neither which makes me "worry" again that it is a framework..
what is MVC - pattern or framework?
thx for any help
[682 byte] By [
CbbLea] at [2007-11-27 5:26:33]
# 1
MVC is a pattern and all frameworks implementing the MVC pattern (JSF, Struts, etc) are .. yes, MVC frameworks.
# 2
> Hi!
>
> In 50% of the websites I've found they count MVC as a
> design pattern, in the other 50% they count it as a
> framework...What is your opinion about it?
That's a very conveniently round split :-)
MVC is a design pattern, or an architectural one, depending on which book you have open at the time. It's certainly not a framework.
> Since design patterns describe "solutions" on
> recurring problems without making it code specific,
> meaning different implementations could make the same
> result this would in my meaning count as a pattern
> while a framework would take into consideration which
> language you are using aswell as stuff like (Swing
> for representing the view etc)
>
> And MVC isn't listed in the GoF book neither which
> makes me "worry" again that it is a framework..
Don't worry at all abou that. The GoF book is just one book, it's not - and the authors themselves make this point - the patterns book. It's a digest of 4 very talented OO designers ideas on software reuse, and no more. It's not meant to be definitive - how could it be? "We've sat and thought about it, and we've managed to identify every single design pattern in the world. Here they are" - would be a bit of a bold claim!
# 3
MVC is an acronym that is used to describe the Model View Controller object-oriented design pattern.
As mentioned, software frameworks that implement the MVC design pattern are typically referred to as MVC-based frameworks.
When used in a sentence when describing a framework, "MVC" is being used as an adjective.
When used in a sentence about the design pattern "MVC" is a noun.
Understanding the difference between adjectives and nouns will increase your ability to communicate with others about software desgin.
# 4
> Understanding the difference between adjectives and> nouns will increase your ability to communicate with> others about software desgin.Not to mention OO design itself!
# 5
Ok, thx for all good replys :)now let's screw those evil 50% framework sites! harhar :)
CbbLea at 2007-7-12 14:47:32 >
# 6
Actually, if you take "framework" at it's more traditional definition (A system of rules, ideas or principles that is used to plan or decide something.) rather than specifically to mean a software framework, it could be argued that MVC is a framework.
So maybe we just kneecap the other 50%, rather than actually butcher them and avail their organs to the black market
# 7
Ok, Now I've read on another site that MVC is an architectural pattern and cannot be counted as a design pattern.
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
As Im writing a paper about design pattern this all confuses me when everywhere I look things are different.. :(
CbbLea at 2007-7-12 14:47:32 >
# 8
So what's the problem? Different people have different opinions about what certain words mean. That's not unusual. There's no need to make a fuss about it.
# 9
> So what's the problem? Different people have
> different opinions about what certain words mean.
> That's not unusual. There's no need to make a fuss
> about it.
Exactly. Particularly since [url=http://www.wikipedia.org/]Jimbo's Big Bag of Trivia[/url] is involved.
If you really want to run round in definition circles for a while, try pinning down exact definitions of the terms "application server", "web container" and "web server". That seems to keep people occupied for ages
# 10
But If i write a paper about Design Patterns (and include an example that MVC is a design pattern) and my teacher don't think it counts as a design pattern. Then maybe I will fail....
CbbLea at 2007-7-12 14:47:32 >
# 11
> But If i write a paper about Design Patterns (and
> include an example that MVC is a design pattern) and
> my teacher don't think it counts as a design pattern.
>
> Then maybe I will fail....
MVC can most certainly be considered a design pattern. I wouldn't worry about that at all. If you want to cover your @ss, include an explanation of how opinion differs on whether MVC is an architectural or a design pattern, and also mention that those terms are both very loosely defined, and open to interpretation. Don't forget that what's often meant by MVC today - in respect of a web application - isn't quite the same as the classic old Smalltalk MVC pattern. Nobody is going to mark you down because the rest of the world is unable to agree on some terminology!
# 12
MVC is a design pattern for creating objects. It is used to design objects that handle the flow of data between humans and computer-based information systems. Software architectures do not specify how objects are designed. Any writing that states the contrary, is incorrect.
MVC is never to used to design software architectures. MVC dictates how an object system should be designed. Architecture dictates what should be created.
A software architecture might specify that a web component should be designed with MVC. And it might specify how all of the components fit together and how service-level requirements, such as performance, maintainability, security are met. MVC is never used to design an application's architecture.
An architecure is created to describe the structure of a software system and how that structure supports business/domain requirements and service-level requirements.
An architecture defines what is going to be built and object -oriented analysis and design outlines how you will build it.
MVC is an object-oriented design pattern, never an architectural design pattern. Again for emphasis, a software architecture may dictate/recommend that MVC be used in the object-oriented design of the web component. Note that the software architecture is specifying that MVC be used, not the other way around.
MVC is typically a small detail of large scale software architecture. The real focus of a software architecture is on the non-technical requirements, e.g. performance, scalability, manageability, maintainability, security, extensibility, etc., of a system.
# 13
I'm not really convinced that MVC cannot be an architectural pattern. Simply stating that your post is irrefutable needn't make it so :-) How are you defining the exact scope of an architecture?
# 14
> But If i write a paper about Design Patterns (and
> include an example that MVC is a design pattern) and
> my teacher don't think it counts as a design pattern.
>
> Then maybe I will fail....
You may notice from the previous two posts that reasonable people can disagree about this subject. So to write a good paper, you should include that fact. And if you have an opinion on the topic, you could include that too.
But if you have a teacher who doesn't care about that sort of thing and just wants you to echo his or her opinions, well, that's too bad. Better luck with your next teacher.
# 15
I mentioned a lot about what an software architecture is and what the Model View Controller design pattern is. There is not much more to say, but if you can articulate exactly what is not understood then I can help. Just to add a bit more...
A software architecture is a blueprint for a software system. It is used to convey how the elements of the system work together. It includes information about network topology, enterprise connectivity, business processes, server-side and client-side presentation.
The most important part of a software architecture are those that focus on performance, user interface, maintainability, and extensibility. Other key elements that are described in the software architecture are resource allocation, process planning, training, monitoring, etc.
A software architecture, in an ideal environment, should not contain details about implementation. Implementation details are identified and flushed out by developers or engineers. That said, an architecture may indicate that MVC can be used to build a GUI for the system if there is one. Again, this does not mean that MVC is used to design the software architecture.
The Model View Controller design pattern is a bit more detailed than other design patterns, such as Mememto or Singleton. This is probably where the confusion comes from. Just because it is more elaborate than most of the simpler design patterns, individuals may jump to think that MVC is used to design architectures. And if one is working on their first Hello World website with a button, then MVC might seem real complex, but it is not.
That said, the details of a software architecture are largely determined by the architect and his/her analysis of the working environment. If there are few senior individuals and the development team if "fresh" off the boat, the architect may create an architecture that is very detailed and contain instructions to use MVC to build a GUI component, or other implementation details including other design patterns and frameworks.
If there are competent senior engineers around, then the architect doesn't need to include any implementation details and can focus everything on the service-level requirements of the system.
SWLEADERSHIP/>
-
For more info see:
http://www.sun.com/training/certification/java/scea.xml
# 16
MVC can describe architecture, in my opinion. You mentioned that an architecture describes how elements of a system can fit together. MVC addresses that. It dictates that there shall be a model, a view and a controller and they should be layered. That may mean at a granularity of, say, a button on a rich UI, but it can also apply at coarser granularity. For example, a typical web application will consist of several factorings of MVC, each representing possibly a whole feature. That is it's architecture. To decide not to use MVC would mean major changes to much of the code. Thus, MVC cannot be dismissed as simply an implementation detail
If we decide that our application shall have a domain model, a framework of controllers and some way of viewing that data as HTML, that is a fundamental decision that is made very early on in the game. It is an architectural decision, not merely a design one. Such a decision is not an implementation detail, there would be a great degree of effort to reverse that decision. While it is possible to turn on a sixpence and say "we shall no longer use the Observer pattern here", the decision to abandon MVC may not be so nimbly executed. MVC, I contest, is not a trifling implementation detail. The way the system is built will be dictated in part by the decision to use MVC.
> The Model View Controller design pattern is a bit
> more detailed than other design patterns, such as
> Mememto or Singleton. This is probably where the
> confusion comes from. Just because it is more
> elaborate than most of the simpler design patterns,
> individuals may jump to think that MVC is used to
> design architectures. And if one is working on their
> first Hello World website with a button, then MVC
> might seem real complex, but it is not.
I agree with what you are saying here. But I don't think it tells the whole story. I contest - as above - that MVC can also be an architectural pattern. Clearly I am not alone in thinking this. Read [url=http://martinfowler.com/books.html#eaa]Fowler PoEAA[/url] for more (and, indeed, for informative reading outwith this discussion). The fact that many of todays J2EE applications are centred around an MVC framework goes a way to supporting this, too: the decision to commit to a particular framework is taken early on, and is not easily changed. I don't think we - as an industry, not the individuals present - have yet satisfactorily defined the lines between software design and software architecture. So while much of what you say is true, I think it is wrong to state that MVC cannot be considered an architectural pattern, irrefutably. Indeed, a web application based on MVC is often described as having a Model 2 architecture.
# 17
Great response! Just to go along with what you said. Yes, architecture describes how elements of a system can fit together. To be more clear on my point, a software architecture does not describe how objects interact/communicate with each other.
The J2EE Model of Development is as follows:
1. Requirements Analysis/Problem Statement
2. Object-Oriented/Architectural Analysis
// Here is where architectural UML diagrams might be created
// Here is where some ideas the GUI needs might be thought about
// Here is where service-level requirements are flushed out
3. Architectural Design - This phase provides a framework within which all the elements work together to satisfy all of the business and service-level requirements. In this phase, implementation details are not included.
4. Object Oriented Design
// Here is where the design of the objects is done and Model View Controller may be implemented if there is a GUI
// Design patterns are used and object reuse is considered
** Note that the common notation for both object-oriented design and architecture design is UML. They are different tasks though, which use a common notation.
Software Architecture and Design is much bigger than J2EE and Java EE. To say that J2EE applications are centred around an MVC framework doesn't mean much. The software written to control strategic ballistic missiles most likely doesn't have a GUI. The software written to control the engine in your car most likely doesn't have a GUI. The software that controls the micro-chips inside your microwave oven does not have a GUI.
My definition of software architecture comes from the teachings of the engineers at Sun Microsystems. Anyone that has completed the SCEA Certification will understand these points very clearly.
For anyone interested, the SCEA Certification has been updated and will be available later on this year. New study material has been published and is available for pre-order from Amazon.com.
http://www.amazon.com/Certified-Enterprise-Architect-310-051-Certification/dp/0071488618/ref=pd_bbs_2/102-6505514-7887356?ie=UTF8&s=books&qid=1180544296&sr=8-2
Hardcover: 624 pages
Publisher: McGraw-Hill Osborne Media; 2 edition (June 30, 2007)
Language: English
ISBN-10: 0071488618
ISBN-13: 978-0071488617
Aside, if the entire application only consists of a web-based GUI with some minor logic and is hosted on a single web server, then MVC, I might imagine could possibly be considered the architecture, roughly :o)
If the enterprise application consists of multiple clusters of nodes with many web servers, many database nodes, many EIS applications, and multiple business applications that all have a single shared MVC-based GUI. Then Model View Controller design pattern can't be considered as an architectural design pattern, in my opinion.
MVC is a design pattern for creating a GUI in a good way, on the Presentation tier. In three-tier applications built with the Java EE Reference Architecture, the meat and bones of the the application is on the Business tier, and MVC is never implemeted in the Business tier.
If someone's focus is Presentation tier stuff like, JSP, servlets, tag libraries, Swing, then MVC is really an important concept to know.
When you are designing an architecture for a enterprise business application, where the meat and bones are in the Business tier, you need to really focus on the service level requirements and satisfying the business/domain requirements. The Model View Controller design pattern is not really useful here.
# 18
Ok, we just fundamentally disagree here, which is in no way A Bad Thing. The OP has seen two very different opinions on the subject, which should provide some good material for his paper :-)
What I will say, though, is that MVC is not restricted to being applied to presentation, and a View need not actually be a UI. The separation of concerns MVC provides is useful in a plethora of situations
# 19
> But If i write a paper about Design Patterns (and
> include an example that MVC is a design pattern) and
> my teacher don't think it counts as a design pattern.
>
> Then maybe I will fail....
If your teacher is like most teachers I've had (and all teachers I've had outside the soft topics like arts) they won't fail you if you come up with reasonable argumentation.
If you just state things they consider incorrect as fact without arguments for it, yes you'll fail and rightly so.
A paper like that is NOT meant to be just a list of pattern names and maybe short descriptions, you can get that from any book or website, copy and paste, and you're ready.
It should include more, most likely shouldn't list patterns at all but talk about what patterns are and do and why they're used (and abused).
Using a specific pattern as an example and maybe providing a short list as an annex would be a good idea, but that shouldn't be the total of your work.
# 20
> It should include more, most likely shouldn't list
> patterns at all but talk about what patterns are and
> do and why they're used (and abused).
Great point!
Design patterns are working designs that software designers can use to help them solve difficult design problems. Design patterns are created by experienced software designers. By using design patterns, software designers are able to develop software faster because the usage of design patterns helps them handle difficult design problems and create code that is easier to get working.
How are design patterns abused?
Design patterns themselves are not a problem. Design patterns are abused when a developer attempts to use them when they don't apply or when they cannot be appropriately applied and the developer deviates from the design. The abuse comes from the developer not the design pattern. This type of abuse typically illustrates a symptom of too much focus of design and a lack of analysis, or in other words focus on requirements. "Coders" are eager beavers, eagerly ready to jump right in and start 'coding', and typically fail to adequately perform requirements analysis. Software engineers typically have more experience and understand the importance of requirements analysis.
