Model View or Controller? Two Simple Questions
Does it Affect the State of your Model?
Does the piece of functionality you are writing affect the state of the application outside of this specific page request? Setting a request specific variable is fine anywhere, but if you are changing a session variable, a cookie, or anything stored in application scope (or persisted via a database, file system or any other mechanism) then you are changing the application state.
The one exception is when you are simply changing view preferences. I would argue that changing the order, filters or records per page for a data set within a view is a User Interface (UI) specific state change and should be handled by stateful UI components even if it is persisted beyond a specific page request via sessions or even cookies.
The purpose of the View is just to display application state (and arguably to persist a users view preferences if you don’t need to use those view preferences for any purposes other than handling view state – obviously if you want to report on a users view preferences, you’re going to have to get your Model to persist them to a log file or a database), so if you are doing anything to change the state of the application it should not be in a View.
Is it HTML Specific?
Imagine that you added three new front ends to your web application: Flex, AJAX and a web service API. They should all be able to speak to your Model code directly. They might need a thin remote façade to handle the lack of session state (in the case of web services) and certain data formatting issues (in all cases – you can’t just pass rich business objects over the wire), but they should not need to access your controller which is simply responsible for taking URL, form and (some) session parameters, turning them into well parameterized calls to the Model and then passing the data returned by the Model to the appropriate View(s).
So, if you have functionality that affects the state of your application and that is not unique to your HTML front end (it is something that your Flex, AJAX and/or Web Service front ends would need to have access to for their model calls to work correctly) then it should be in the Model.
A Pragmatic Approach
The benefit of the above “two question test” is that it makes for more flexible, maintainable code. From the lists I get the impression that a lot of MG and M2 apps would not be trivial to retrofit with a Flex or AJAX front end calling the model directly (via a thin remote façade) because a lot of state flow or even business logic has been hard coded into the HTML front controller. This is not a weakness of the frameworks - it is just a matter of how they have been used. You could even reasonably argue that the Model/Controller distinction isn’t terribly critical if you never plan on adding non-HTML front ends to your application. This is true, but I personally find it easier to follow a generally applicable best practice consistently between applications to ease the process of getting back up to speed with each project for maintenance (I maintain about 100 projects, so ramp up time is a real concern!).
It is interesting the dividing lines that come up (and the questions that arise) when you follow this approach relentlessly. For instance it makes you think about the distinction between View, Controller and Model use of the session state and it shows that in a rich application all three parts of your application may well need to interact with session state. Views may use session state for persisting records per page or display order preferences for given pages as a user navigates through your site. A Controller might use session state to implement a three page form based wizards, storing the partial answers within the “conversation” in a session bean (this would be appropriate if your alternate Flex or AJAX front ends would have simply used a client side approach like tabs to implement the three page wizard, returning just a single completed bean to the Model). A Model might use session state to implement continuation server like or more sophisticated wizard based functionality in cases where you would have asked the Model to manage application flow irrespective of the front end being used.
Any thoughts?!
CMCV would be better. Controller, Model, Content and View. Let's say you have an application that serves up content as HTML, HTML/AJax/Flex. Three different ways to view content. (and there could certainly be more.) The concept that view can serve content differently is fine, but generating content in the model isn't a plain concept. (Not to mention that there can be application logic also that is outside of the model. The controller should control what and conditionally if something is called. Again... this is all confusing. On top of that it is about as easy for a developer to create a proper layer of software as it is for them to create a well normalized database. Both can be done but it takes experience. Reading a book on normalizing requires that someone has used databases enough to understand the "application" of the concepts. The same is true for knowing how to write a clean applicaion with MVC (or a better constructed model.) Reading a book on design patterns is confusing if you don't have a sufficient base.
This is the main problem with MVC. What does it take to be good at application design for MVC? Typically you need to start by knowing the language and good database structure. Then you need to know how to build functional abstraction with your objects. (LOL, and we know that statement will loose people on it's own!) That is my point. We need a system that allows someone to walk up the stairs rather than requiring them to climb the mountain without good safety ropes. (Design Pattern books aren't enough to help people walk the path.)
I agree with you that learning MVC takes some work just as learning OO takes some work. An interesting post was made recently though asking "what is wrong with programming being hard". Programming is fundamentally a necessarily difficult task. We aren't looking for paint by numbers kits that will allow a nurses aide without training to perform heart surgery, so why are we looking for ways that scripters with minimal formal programming education (self taught OR in a college) can create sophisticated, mission critical maintainable web apps.
I'm working on a software product line for deskilling the generation of a wide range of mid market custom web apps, but architecting applications (like architecting buildings) is necessarily (as opposed to accidentally) hard and there is no single silver bullet.
Second, there seems to be a belief that you have to make things hard to make mission critical apps work. Hard isn't the only path to lifecycle stable technology.
I agree that until things get simpler they are better hard than unapproachable. Yet, what I see in some circles is people building enterprise concepts into what they promote as common frameworks. The common man finds things so "hard" that they move to PHP or Dot Net. In fact some have even moved from CF to Java. At least the UML tools can actually code objects there... so the tools take the hard stuff and make it easier. (We need better tools if we are going to make CF harder.)
Those are just a few of the reasons I don't encourage people to do things that are hard. AND BIG LOL at your heart surgery analogy. Programming isn't heart surgery... it's more like planning a diet. Eat wrong and it will show up... and the longer it takes to show up the more seious it can be, and harder to resolve. Do you want things simpler outside of your profession or harder. Do you buy a car based on user interface being more complex or more simple? Look at Jet consoles! They have gotten progressively simple! Lastly... are you aware that heart and brain surgeons are constantly looking for ways to make things simple also?
I think we're in agreement. I agree that people should work their way up to soloing El Cap by top roping a simple 100 ft pitch on solid granite with good jug holds and an experienced climber on the rope (I used to climb quite a bit, so thanks for the analogy!). I also agree that all of us should be looking for ways to make things easier. Everything from ColdSpring to Mach-II is designed to make powerful things more easy. However, learning each of those tools means that building more complex apps still requires more knowledge than building simpler ones and it is quite reasonable that building a scalable and maintainable application would be harder than building a single page script - even as we all do our best to make it as easy as possible.
The problem is that people start with a simple application and they don't realize that as the complexity grows the skills required to maintain the application also grow. Being able to create one page that works with a database requires less skills than writing an application composed of 1,000 pages each interacting differently with a database. There is a fundamental cost of increasing complexity that includes step functions (such as moving from procedural to OO programming) and while you can decide when to make each step, the longer you postpone it the harder simpler changes become in your application. If you've ever built an application that evolved and that you're now pretty well too scared to touch (I have) then you'll know what I'm talking about!
With that said, knowing appropriate boat design patterns for canoes is very helpful. The issue is that since we call everything "design patterns" the guy who wants to learn how to build a canoe fast and reliable is going to find it easier to swim. (Translation... forget building a web site! It's worth the amount of trouble.) What happens as a result is they build it with ASP or PHP. Not because those platforms are easier, but rather because someone made things to hard, and the customer moved away from ColdFusion.
We need to realize the the scope of design patterns required is determined by more than the euphoria of philosophy. Before PETA outlawed the phrase there as a cruel cliche, "there is more than one way to skin a cat". Bottom line, way to often we geeks show how much of a geek we can be... and rather than focusing on the task and lifecycle we are preparing our fruit stand to scale and compete with Walmart, Meijers and the like. That is my point.
I see a time for hard, a time for complexity and think things like IOC belong to keep things from getting out of hand. But sometimes we fall in love with IOC so we put desing patterns into something like a FAQ program. If that's someones style and the person paying the bill likes that, enjoy! For others... you just don't need to make things harder than they need to be and adding another layer to make things simple is only appropriate if the complexity was needed in the first place.
There is NOTHING wrong with not using design patterns or OO. I would say that anyone well versed in them would only recommend using them for two reasons: because the application needed the pattern to handle the complexity and that outweighed the cost of the additional indirection, or as a learning aide so you're capable of recognizing and using the patterns if required for a project. Both are valid reasons.
But as I said, send me the links to the articles suggesting using frameworks and complex design patterns for a FAQs page so I can post a comment at the bottom strongly disagreeing with them. Looking forwards to the links!
Best Wishes, Peter