MVC considered harmful
[Ed. note — I posted this last year as I was learning the Flex framework. Since then, I’ve built a few Flex projects, and for some of them, I found myself using MVC, although I typically use more of a SmallTalk-like MVC pattern rather than a struts-like FrontController. Another data point is that since last year, I’ve talked to lots and lots of people who have tried Cairngorm, and 95% of them seem to like using the FrontController pattern so take my opinions with a grain of salt. –Sho, Apr 2006]
Recently, I’ve been thinking about the appropriate way to wire up Flex applications, and I’ve come to the conclusion that… drumroll please… MVC is probably not needed for most RIAs. Or more specifically, application of the FrontController pattern is probably overkill for the vast majority of Flex apps. (I know that Steve and Ali are going to disagree with me violently…)
~
Let me caveat all this by confessing my general tendencies as a programmer and engineering manager, which can be summarized by one word: laziness. And as a lazy programmer, I’d never really gotten into MVC in desktop GUI programming. For me, separation between view and model was the important thing. Separating out the controller from the view seemed to be more trouble than it was worth.
MVC actually makes sense for the HTML-based world, because there is a physical separation between the view, which lives on the client machine and the model, which lives on the server machine. Logic to respond to user events usually needs to be handled on the server. Does it make sense for the model to take care of these events? Of course not. Ergo, you need to separate out the controller logic from the model logic.
There are nasty things about this approach as well. You often see architectures in which a single controller handles all of the “actions” for the entire application. I see this as a necessary evil, not a “good thing”. The world of the giant switch statement is exactly what we wanted to avoid with OO programming, right?
With Flex, you have a powerful engine on the client that can perform complex logic and directly access Web services. Because of this, the forces that propelled everyone to adopt MVC need to be reexamined.
For some applications, it may make sense to separate out controllers for the application. And for certain components, it will probably make sense to use the MVC pattern for that component just like in the Smalltalk days. But for the majority of apps, I think that separating the view from the model is the big win, and in most cases, the “model” part of your application consists of services that live on another machine, so that separation is something that you have no choice about.
Ok. Flame away!
P.S. Heidi, our engineering manager, came back from sabbatical last week, so my days are becoming a little less hectic, hence this post. *whew*!
I agree, separate model and view is enough, controller sometime is abused
Guess who :) OK, I’ll humour your idea for a second :-) Consider an application with 100+ use-cases, or user-gestures, that will consequently result in service calls with asynchronous data returns. Consider that a team of 20-30 developers maintains that code base, and by the changing nature of enterprise application development, does so in a collaborative manner whereby no single developer will have ownership of their own corner of the application, but will be expected to add functionality all over the architecture.
How, architecturally, would you recommend that developers implement the “user gesture to business logic execution” code without some sense of application controller ? The controller being a big fat switch statement – bad code smell, without a hazard of a doubt. But a controller as a dispatcher of control – where’s the bad smell in that ?
It’s interesting that you see the controller as something monolithic and fundamentally unmaintainable, whereas I see it as a pattern that emerges to bring structure and sensibility to code that had no sense of central handling of user-gestures, and instead sees multiple developers using multiple methods scattered over multiple different logical tiers in the presentation architecture, to handle it.
Caveat — if “most applications” are single or few developer proofs of concepts, then I agree in the overkill of the controller. But I don’t believe, ultimately, that the value of Flex is in creating these small development team, small number of use-case applications.
So … is the controller *really* a bad practice, or is just different strokes for different folks ?
Very much look forward to your response.
Sho,
I’m currently finishing a 100+ screens Flex 1.5 application, and I can swear so far I really can’t see how I could have done this without a clear, separated implementation of use cases that an MVC application framework (Cairngorm in my case) offers me.
It is about structring application + having separated use cases + code readability and understandability. I could have done without MVC but I would have end up completely mad, wiring tons of user interactions.
Cheers, r0main
I like MVC, but I rarely use it as it is defined by the “Gang of Four.” The View and Model patterns are standard, but my Controller also utilizes the Mediator pattern to allow my models and views to be decoupled completely.
Interesting… You may want to cross reference that with the Macromedia Certified Flex Developer courses. They would disagree with you. Christophe I think, would have a different opinion as well. I like using MVC in Flex for the following reasons:
– Main.mxml as the controller with reference the model and views
– Easy to add new views/components on the system
– Easier for maintenance and working with other developers
– Better logical flow and understanding the application
– My MVC apps have never been easier architect and develop (that includes Mach-ii, Flash Remoting, and of course Flex)
Maybe you should do more projects, have them suck because of the lack of a decent architecture, and then you’ll appreciate & perceive MVC as more of a necessity vs. a chore.
Boy Steven, you make it sound like any project that doesn’t have 30+ developers working on it sound trivial.
The company I work for doesn’t have 30+ employees and we all work on a variety of projects ranging from the enterprise class to the laughably trivial.
However, I agree with your point about MVC bringing order to the chaos. I honestly haven’t had an excuse to use Flex, but in general, I like MVC – it makes sense with any non-trivial web-based project I have worked on.
I can’t even imagine the chaos of having 30 people working on each of our projects though. The communication nightmare that could take place with that. Ugh.
Morphic replaced MVC in Squeak for the very same reason. Morphic is very close to the MovieClip model and is very easy to implement. I love jumping through firey hoops but simpler is better in the long run.
Here are some morphic links:
http://minnow.cc.gatech.edu/squeak/30
http://www.squeak.org/tutorials/morphic-tutorial-1.html
http://research.sun.com/research/self/papers/self4.0UserInterface.html
http://www.cc.gatech.edu/fac/mark.guzdial/squeak/startingmorphic.html
http://research.sun.com/research/self/release/Self-4.0/Tutorial/
http://www.powersdk.com/ted/2003/05/gone-morphic.php
Cheers,
ted ;)
Well, it’s good to see that people are paying attention! :-)
For starters, Jesse is right in pointing out that I haven’t had the experience of writing tons of crappy web apps with bad architecture. I’ve spent my career working on desktop software, which is completely different, which is why I rely on comments like these for me to get a better understanding of how things work in the real world.
That having been said, here’s my thinking:
One of the reasons that people build controllers is to isolate the interaction logic from the view, with the goal of being able to swap out the view. The problem with this approach is that with the richer UI vocabulary that RIAs allow, I believe it is not possible to do this.
For example, let’s say you write controller logic for an e-commerce app. The controller logic takes care of model changes (e.g., “add to cart”) and view changes (e.g., “view my cart”). Later, you change your view so that your shopping cart is always visible while you are shopping. The controller logic has to change as well. And the richer the interactions become, the harder it is to write the controller logic to be impervious to view changes.
There are also issues with encapsulation. Let’s say I have a TabNavigator control. When the user clicks on a new tab, should that action go through a controller? It obviously depends on the situation, but what are you gaining and what are you losing by routing things through a controller?.
This is different than HTML, because in the HTML world (pre AJAX), you needed to talk to the server in order to do most things, such as navigating to a new tab, so you may as well wire it up through the same controller as your other actions.
In the world of RIAs, there are more ephemeral events as well. What about hovering over a particular bar on a graph to show a tooltip? Should that go through a controller? What about hovering over a button to make it glow? What about showing cursor feedback?
Depending on your programming style, you may fall all the way down this slippery slope to arrive at the conclusion that in general, it is OK for view changes to be handled directly by the view as opposed to going through a controller. If so, the controller is now a conduit between user events and model changes.
Sometimes, this isolation is helpful. The client side application may need to be insulated from changes in the back end services. But in other cases, the back end services may be rock solid, and the controller just becomes a pass-through delegate to the service layer.
So to wrap it all up: I’m not sure I understand the benefits of separating the view and the controller, and I believe this way of working can introduce complexity and cost to projects.
BTW, I agree with Steven’s comments about asynchronous programming being difficult to deal with. That’s a new angle that I hadn’t considered previously. I’ll have to chew on that one for a bit…
I also agree with Steven’s comments about size of project. If a “typical” Flex app has 20-30 developers, stronger separation between various parts of the application becomes more critical.
On Design Patterns and Reality
Fact: No one codes Flash using pure MVC. One of the things I try to emphasize with developers is that the only absolute in programming is that there are no absolutes. Patterns are architectural heuristics. Understanding them should widen your solution …
Was going to comment here, but it got long, so I wrote a blog entry instead. :)
http://www.gskinner.com/blog/archives/2005/08/on_design_patte.html
> For example, let’s say you write controller logic for an e-commerce app. The controller logic takes care of model changes (e.g., “add to cart”) and view changes (e.g., “view my cart”). Later, you change your view so that your shopping cart is always visible while you are shopping. The controller logic has to change as well. And the richer the interactions become, the harder it is to write the controller logic to be impervious to view changes.
In a well-written MVC, you wouldn’t need to change the Controller just because the shopping cart is now always visible…
>…the controller is now a conduit between user events and model changes.
When user events change the model, yes. Views can and should have their own interactivity, and if interactions with the view don’t change the model, then they shouldn’t be hitting the controller. Isn’t that what MVC was all about?
Well, my understanding of controllers was that they typically control both model changes *and* view changes, even when they don’t affect the model.
For example, in a struts based application, if I were on a page that showed a list of things, and I wanted to view the list with a different sorting order, that would be routed as an action that would be handled by the controller.
And again, imagining a struts controller for the eCommerce app described above, there would be an action associated with “view my cart” which would be handled by the controller and lead to a view change (redirect to shopping cart page).
As for model/view separation, I think it’s critically important, which is what I said in the original post. Separating out a controller layer separately may or may not be as important, depending on what your back end API is like.
One of my main issues with the whole framework/mvc debate is that it has been my experience that one size can not fit all. There are applications where it makes sense to use MVC and framework “X”, there are applications where it makes sense to use MVC and framework “Y”, and there are applications where a framework adds unnecessary overhead and complexity ( translating to cost).
I approach each project as unique. I evaluate it and try to choose the tools that best fit the project.
A hammer is a great tool, but maybe not the best one when you are holding a screw!
Immediate apologies for length of this response, but I’d rather keep the thread going here, than split across blogs…ok with you ?
SHO:
One of the reasons that people build controllers is to isolate the
interaction logic from the view, with the goal of being able to swap
out the view. The problem with this approach is that with the richer
UI vocabulary that RIAs allow, I believe it is not possible to do
this.
STEVEN:
I’d like to pull you up right there; I’d really not want to
suggest that a motivation for a controller is to enable the easy
switching of a view. Correct binding between a model and a view
should mean that the view implementation is oblivious to the model,
and that updates to the model should have no assumptions about how
these updates will be rendered by the view. Flex data-binding allows
us to quickly develop complex-views that observe/listen (if anyone
wants to get into a debate about the differences between observers
and listeners, you can email findSomoneThatCares@iterationtwo.com) to
complex models. So if we make decisions about whether a shopping
cart should be always visible, or in a popup, or a panel, or rendered
in small/medium and large views, then those are all just a *simple*
case of authoring different implementations of the view, each of
which are bound to the same, in many ways ignorant, model. Getting
the controller in the way here would be just that – getting it in the
way.
SHO:
For example, let’s say you write controller logic for an e-commerce
app. The controller logic takes care of model changes (e.g., “add to
cart”) and view changes (e.g., “view my cart”). Later, you change
your view so that your shopping cart is always visible while you are
shopping. The controller logic has to change as well. And the richer
the interactions become, the harder it is to write the controller
logic to be impervious to view changes.
STEVEN:
I’d dispute this; the controller would recognise one of several
gestures (clicking [add to cart] button, or dragging and dropping an
item onto a cart) and it would dispatch control to a worker class (a
command) that performs the business of adding an item to a cart.
That command class would encapsulate *behavior*. Is this item
already in the cart and so we don’t add it to the cart, but we
increase the quantity of the current item by one ? Is there a need
to round-trip to the server and check whether the user is allowed to
purchase this item X when they live outwith the US according to their
registration details ? Does the update to the total price just
include the price of the item, or have they placed something in their
basket alongside another product that together constitutes a special
offer with a discount ? My point … there’s often complex business
logic that sits between the user gesture and the updating of the
model, and the command and control strategy provides a consistent
location for that business logic. Otherwise, some developers place
that as inline handlers in a click=”” on a button, some put scriptlet
in the MXML, some write a utility class to encapsulate that logic,
some choose to abstract that logic in the addToCart() method on the
model, while others don’t. The bottom line – without consistency,
multi-team collaborative development quickly degenerates into “that’s
the shopping basket code, you better get Adam to fix that, he wrote
that bit..”. So let the command manage all that business logic, and
let the final thing the command does (synchronously if there’s no
server round-trip, and asynchronously in a result handler if the
business logic requires the interaction of data services) be to
update the model.
If the view changes — well, all that business logic remains the
same. Whether you have to hit data services or not remains the same.
But the need for the controller to dispatch control to a command, and
for the command to update a model, doesn’t change. So the business
logic remains concrete. You change your view, you make sure that view
binds to the old model in the old way, and you make sure your view
dispatches whatever events your controller needs to delegate a little
responsibility for (such as my addbasket stuff above). But your
controller isn’t brittle, it doesn’t break or require change because
your view changes.
Make sense ?
SHO:
There are also issues with encapsulation. Let’s say I have a
TabNavigator control. When the user clicks on a new tab, should that
action go through a controller? It obviously depends on the
situation, but what are you gaining and what are you losing by
routing things through a controller?.
STEVEN:
I wouldn’t route that through a controller. To me, you click on a
tab, you’re changing the *state* of the view. On my model, I’d have
a state object (in the most simple implementations; in a deeply
complex implementation this might evolve to become a state-machine
that enforces state transition rules as well as recording of state).
So, in your TabNavigator change you’d cause something like
“Model.viewState == Views.UPDATE_PAYMENT_DETAILS”, and you’d use data
binding to bind the selectedChild to the viewState on the Model.
So again; the view renders itself according to the state of the model
— no need for a controller interaction here, because there are no
business rules, there are no data services.
Make sense ?
SHO:
In the world of RIAs, there are more ephemeral events as well. What
about hovering over a particular bar on a graph to show a tooltip?
Should that go through a controller?
STEVEN:
No way.
SHO:
What about hovering over a button to make it glow?
STEVEN:
No way.
SHO:
What about showing cursor feedback?
STEVEN:
No way.
SHO:
Depending on your programming style, you may fall all the way down
this slippery slope to arrive at the conclusion that in general, it
is OK for view changes to be handled directly by the view as opposed
to going through a controller.
STEVEN:
I don’t see that as a slippery slope, I see that as the simplest
solution that works, and works well.
SHO:
If so, the controller is now a conduit between user events and model
changes.
STEVEN:
Eureka! It’s a conduit between user gestures or system events
(perhaps a server-side data push from Flash Communication Server is
heard by the RIA client and can cause the broadcast of an event, say
StockAlert, along with some server-side generated data) that impacts
upon workflow, data services and perhaps ultimately, updates to the
model. And I think this is why we wouldn’t use a controller in a
desktop app, but would in an RIA … as an RIA is still having to
manage data-services interaction, it’s still in that no-mans land
between thick and thin-client, but it’s certainly not a desktop
client.
SHO:
Sometimes, this isolation is helpful. The client side application may
need to be insulated from changes in the back end services.
STEVEN:
We’d handle this however using the macro patterns of business
delegate and service locator; we’d abstract the location,
implementation and contract of services from the commands that
require to use them. However, the controller should (and does) play
no part in making that insulation. Unless you’re building baby-Flex
apps where you just call RemoteObjects from definitions scattered all
over your code, but then no self-respecting Flex developer will hang
out with you anyway.
SHO:
But in other cases, the back end services may be rock solid, and the
controller just becomes a pass-through delegate to the service layer.
STEVEN:
In light of all I’ve said above about the business logic that may be
encapsulated between a controller and data services call, do you now
agree that it would never/rarely be a simple pass through ?
SHO:
So to wrap it all up: I’m not sure I understand the benefits of
separating the view and the controller, and I believe this way of
working can introduce complexity and cost to projects.
STEVEN:
Define complexity … is an extra layer of indirection that
introduces consistency across a development teams implementation of a
solution, the introduction of complexity ? Define cost ? Is a few
days of effort on your first ever Flex project to understand a
microarchitecture, not going to achieve return on investment when
your cost of change, maintenance, is reduced ? When the cost of
sitting a new developer into your team midway through a project and
having them understand the big picture and the fine detail in one
sitting is a real by-product of your architecture, is that a cost, or
a saving ?
SHO:
I also agree with Steven’s comments about size of project. If a
“typical” Flex app has 20-30 developers, stronger separation between
various parts of the application becomes more critical.
STEVEN:
I would only really advocate that microarchitecture be embraced when
there are motivations; I’m not an advocate of “big up-front design”
and so to make the decision to embrace an architecture we need to be
clear of the motives for when injecting some up-front design is
appropriate. For smaller applications, proofs of concept,
“disposable RIA”, the benefits might not be there to be reaped.
However, as we see these concepts catch-on in the community, we see
people working them into smaller educational projects, and those are
the projects we tend to hear about. However, I personally know of a
significant number of real-world and massive Flex application
developments going on right now, where an RIA microarchitecture, be
it Cairngorm, a derivative, or a home-brew implementation of MVC is
at the heart of the implementation, and what is more, the development
team are enthusiastic of the benefits they are gaining from it.
So a flip-side question; in your experience of developing large
desktop apps with large development teams, what strategies would you
typically use to centralise the handling of user-gestures and the
dispatch of control and workflow, and do you think any of these
strategies offer alternative application in the field of RIA ?
You know what Sho; I think you and I are locked in violent agreement,
that a solution should be as simple as it is elegant, that it should
express intent yet allow maintainability, and that it should leverage
established best-practice without being afraid to step up and say
there’s a better way of doing things.
I can’t imagine a good programmer not separating out control logic in some way. Even if it is in a view class would you not encapsulate it in one or more methods?
As an application gets more complex so does the control logic. We have an application with the screen split into a minimum of 5 areas with other areas coming and going. Which view would control this? You could extract this into a ViewManager or WindowManager, but isn’t this just control by another name?
Oops! Spot the Java programmer. For method read function.
Thanks for the thoughtful answer, Steven. I agree with your overall conclusion, which is that we probably agree more than we disagree.
Here’s where we agree:
—
1) For view changes that don’t require a model change of any significance, a controller is not necessary. This is quite different from previous Web frameworks such as struts, in which a server round trip was needed to mediate view changes, which meant that even trivial view changes would usually be routed through a controller.
2) This is also different from the original Smalltalk MVC decomposition, in which things like TabNavigator *would* use a controller to mediate between the user event (clicking) and the model change (selected tab is changed).
3) When “business logic” needs to happen on the client, it should be separated out from the view logic.
4) Controllers can be a useful way to organize functionality in a central place when teams and projects get large.
And there’s one point where I’m not 100% sure we agree:
—
5) My preference is to encapsulate business logic in the model, not the controller.
STEVEN:
Is this item already in the cart and so we don’t add it to the cart, but
we increase the quantity of the current item by one ? Is there a need
to round-trip to the server and check whether the user is allowed to
purchase this item X when they live outwith the US according to their
registration details ? Does the update to the total price just
include the price of the item, or have they placed something in their
basket alongside another product that together constitutes a special
offer with a discount ? My point … there’s often complex business
logic that sits between the user gesture and the updating of the
model, and the command and control strategy provides a consistent
location for that business logic.
STEVEN (in a later section):
We’d handle [isolating client side code from back end services] however
using the macro patterns of business delegate and service locator;
we’d abstract the location, implementation and contract of services
from the commands that require to use them. However, the controller
should (and does) play no part in making that insulation.
SHO:
I think I agree with you here, but let me elaborate. For starters, I would imagine that you have a set of server side services, perhaps wrapped up in a server side object, and a client side object that intermediates between the application and the server side object (which you call a business delegate). In my mind, most of the logic you mention in the first paragraph above should be in the business delegate, not the controller.
// psuedocode
class ShoppingCart
{
function canAddToCart(itemId: Number) : Boolean;
function addToCart(itemId: Number) : Result;
function getCount() : Number;
function getItemAt(index: Number) : ShoppingListItem;
function getTotalPrice() : Number;
}
You would ask the business delegate whether you can add to the cart, and to compute the total price, which means that this logic is bound to the model. As these changes happened, events would fire which would be picked up by the view. If you use the business delegate as the consistent place to put as much of your business logic as possible, the controller becomes very thin. My own opinion is that it would be ok for the view to call the model directly for apps in which the controller had basically nothing exciting to do.
Things, of course, get tricky when user interaction comes into play. For example, if you need to pop up an alert that asks the user a question before completing the transaction. In these cases, I agree that having another object is helpful (I would call it a command, rather than a controller, but I think that Java guys may think of commands as a type of controller).
Finally, a question from Steven
—
STEVEN:
So a flip-side question; in your experience of developing large
desktop apps with large development teams, what strategies would you
typically use to centralise the handling of user-gestures and the
dispatch of control and workflow, and do you think any of these
strategies offer alternative application in the field of RIA ?
SHO:
The funny thing is.. we often use things that are very much like controllers for desktop applications, although we don’t call them that!
MFC, which is the old way of writing Windows apps, has something called a message map. I personally don’t like it very much, but it turns all user gestures into numerical message IDs, which percolate through the view hierarchy and document list can be handled by various objects (are these controllers? they are part of the view hiearchy, so I think not…). For example, when the user picks the “Cut” menu item, it turns into an EDIT_CUT message, which can be captured by either the view, the document, or the application ojbect. Operations such as “cut” tend to be the most tricky to wire up, because they need to do different things in different contexts.
In .Net, there is no such thing as a message map, and there is no notion of actions or controllers. All of this wiring is left as an exercise to the reader. I’ve never built a large scale application in .Net, but I would probably end up wrapping up actions into command objects that encapsulate their undo behavior.
On the Mac, the recommendation is to perform all actions by posting messages to yourself in the same way that AppleScript would call you if you were being automated. This is very much like Sun’s FrontController pattern.
Previous to Zorn, I headed up a project in which (among other things) we created our own message routing system + command dispatch system, etc. The dispatcher allowed multiple controllers to be in scope at the same time, and would route commands based on the currently active controllers. These, in turn, would delegate to command objects which encapsulated undo behavior, etc. So it’s not as if I’m saying we should never use controllers!
The main forces that push desktop applications to pump all user actions through a main switchboard have to do with concepts that don’t necessarily exist in RIAs: macros (AppleScript), undo, main menu, etc.
What I’m hearing from you is that there are other forces in the RIA world that make it useful to have a switchboard (network architecture, etc.)
Anyway.. this has turned into a great conversation. Thanks!
Hey guys… late to the party here, but I’ve got a couple questions/comments.
Before I say anything else, let me say that I have minimal experience developing anything in terms desktop apps and I’ve been thru a few Flex tutorials. If you count PowerBuilder, I’ve played at desktop development a bit… but not much. I’m a ColdFusion developer and have been since ’97, though, and I have been programming since I was 9; point being I’m not completely ignorant. ;)
As far as desktop development on the Mac, I’ve been going through the tutorials for Objective-C that came with xCode… and Apple spells it out pretty plainly in the docs that Cocoa is an MVC framework for developing OO desktop applications. All the tutorials specify how to create the controller, model, and view objects; and using Cocoa, it handles any changes in view state (like glowing rollovers and undo actions) all by itself. So Sho… I’m curious about the conflict between what you’re saying about desktop development on the Mac and what all the tutorials and doco say about it.
Next thing… a quick point about development for a traditional web-application (from my perspective). For the MVC apps that I’ve worked with using ColdFusion, it’s about how the query string and form data make it into the controller class, how the model may be altered and update the database and shared scopes, and how alternate view fragments may be substituted to fill the output buffer that CF returns to the browser. MVC makes view “fragments” possible in our world… but since it’s all based on request/response cycles it’s a whole other world.
So I’m absorbing this thread, and I see the question forming… if you need to send an onMouseOver event to a controller instead of just changing state on the button in the view, what do you gain? I’m glad Steven answered those questions… because my first reaction was “no way” but I’m no front-end guy, so he confirmed my feelings. Changes like that have no need to go to the controller (unless it’s a dedicated view controller of some sort). Only things that change application states (be they persistent, session-specific, or application-wide) should be sent to a controller who can dispatch the instructions to model classes and then the results of those changes can be passed back from the model to the controller. “Controller” in this case stands to receive messages from the user, “use” the model to carry out those instructions, and then update the view.
Although… as I think about this, when doing desktop development, the question becomes more complicated. If you’re doing a word processing application, is the keypress sent to the controller, added to the document via the model, then the view is refreshed via the controller? Or is the model used to save changed files and the view handles all the live updates to the text?
Hehe… see? I’m learning, so be gentle. ;)
Laterz,
J
For another example, and with reference to Sho’s comment on MFC’s handling of events, Cocoa uses the concept of a responder, first responder and a responder chain to handle events.
The focused view is the first responder and has the opportunity to handle events. If it doesn’t handle the event it gets passed up the responder chain (usually the view’s container, then window, then window controller and finally the application controller).
There are sensible defaults for the responder chain set up by the Cocoa framework but you are a free to programatically modify the responder chain as needed. For example, I’ve utilised the responder chain when implementing ‘tools’ in a state-like fashion where both the current tool and toolbox (the tool manager) is inserted into the responder chain to be able to handle events.
The responder chain idiom in Cocoa obviously borrows from the chain of command pattern, but you’ll find no reference to the chain of command in the responder documentation. Why’s this? The most important part of an abstraction is not what patterns it strictly adheres to, but what it provides the programmer in terms of power, maintainability and ease of use.
… and back to the discussion on MVC: my ‘tool’ abstraction encapsulates user input processing, drawing transparent scratch information (for example to display a selection rectangle) and model object manipulation. Is the tool a controller or a view? Could it even be a model (at the application level as opposed to the document level)? The answer: who cares. These labels we use are for architectural communication and education, not as rules that must be adhered to regardless of the problem domain.
A more important question than “do your developers implement design patterns?” is “do your developers *understand* design patterns and spend the time creating, analysing and discussing abstractions that may enhance the design of your application?”
Sho,
Congratulations on such a bold subject title. Without it, how could you ever get folks to so pationately be defending the meaning of life. ;)
However, beyond an academic discussion and/or your own desires to ensure that Zorn internals are solidly architected, why is there this discussion ?
That is, are you working on a development environment or a framework for development or perhaps both ?
Hi Sho,
For the past 6 months my team and I have been working on this theoretical “e-commerce app”.
MVC seemed the obvious solution as our store would have multiple views (pods) that needed to be updated. And since we would be using multiple pages, we used a HMVC pattern (Hierarchical MVC) to accomplish it. By month two, I was frustrated by the complexity that simpler pages were implementing. It seemed that we’d made a mistake and we’d be paying for it. By month four, I was relieved that we were using an MVC approach, because features began appearing which required more business logic on the simpler pages and it was easier to add. If we had simply done without the controller, our classes would have become unwieldy and bloated. So though I’m a believer in using what you need (KISS), for flexibility’s sake, MVC allows for a lot of room.
And the argument that it requires more changes to different classes is erroneous. Those same changes would need to be made, and we’d be left code that isn’t separated into what it is.
But each developer knows his project’s need best (I would hope).
Wow! Lots to answer…
J: Cocoa looks to be much more MVC than Carbon, which is what a lot of us in the industry still use (because of legacy code + a lack of enthusiasm for moving to Objective C). When I talked about how the command plumbing for Mac software works, I was referring to Carbon, not Cocoa.
Tim: I think you and I are on the same page. Patterns, such as MVC, chain of command, etc. are great things to have in your mental toolbox to use where appropriate; putting certain design patterns on a pedestal and invoking them reflexively without really understanding when/how they should be applied is a problem.
Zdravko: My question really has to do with RIAs (what you write) as opposed to the architecture of Zorn (what our team writes). We got dragged into a discussion of desktop apps as a kind of detour when Steven asked whether our experience from writing desktop apps might shed light on how to architect RIAs.
James: Great input! Hearing from someone with a KISS sensibility that the initial frustrations with MVC were counterbalanced by real benefits is a great data point for me.
Tinic & Sho
Tinic & Sho: After pointing to Tinic Uro’s blog below, I realized some similarities/differences with Sho Kuwamoto’s writing — they’re in dramatically different places on their product cycles. Tinic is just wrapping up a round of development on the Mac…
Just my two cents
http://home.in.tum.de/~pittenau/ModelViewController.mp3
http://www.oreillynet.com/pub/wlg/3533
Hi Sho,
Use a controller as the initial point of contact for handling a request. The controller manages the handling of the request, including invoking security services such as authentication and authorization, delegating business processing, managing the choice of an appropriate view, handling errors, and managing the selection of content creation strategies.
My Experience as System Analyst and Software Engineer leads me to disagree with what is just proposed. MVC pattern is one of the most necessary design patterns specially when it goes about distributed applications.
Well, in OOP we can implement the FrontController pattern in a very powerful way, just with using Inheritance and registering the appropriate Controller for the appropriate Service, the solution would be clean (and not just like switch statement).
In addition, just consider the case (in the real Business world) when you need to deploy a program (which also holds the Controlling) on the client machine:
1- The client would refuse to install any program on any of his machines.
2- What about updates. You have to reinstall the program for times and times …
3- What if u had n copy of different versions from your program on the machines !!!
4- What about debugging ??
5- What about deploying issues ??
6- What about security! when u’ve ur program installed on the client machine and doing business login in the client’s memory!!!!
I think that the separation between the View and Control is more than important in real life business applications, otherwise the hackers would feel happy to find the government control installed on their machines.
Eng. Kais Sam.
MVC is fine so long as you aren’t trying to pretend you’re not producing a web application. Anyone who justifies MVC as a way of making a web app “like” a desktop application’s MVC architecture is fooling themselves. The internet just doesn’t work that way. I’ve seen IT budgets balloon and schedules run late because of the blind, over-zealous switch to MVC, while chanting “industry standard” to anyone who asks “why?”
I also often hear a lot of discussion focused on the model or controller part of the pattern, however in many projects that I’ve seen the “view” requires a software engineer in order to make modifications to the GUI. This simply is not the reality for every web project. Web designers should not be forced to work around artifacts introduced by a software engineer’s programming framework. If the cosmetics of the application cannot be changed without the involvement of a software engineer, something is wrong.
IMO, you can achieve the goals of MVC without the big, fancy application server that Big Company is trying to sell you.
MVC is a very good design pattern…but it has it’s place. You can’t make it work for everything. I’ve “bent” the pattern a few times to make some applications work the way I needed, but I understand that I would’ve been better off using another approach. I personally like the MVC pattern because of organization BUT as mentioned somewhere in these comments above…it’s more important for real life business applications. MVC doesn’t make too much sense in other situations – especially some of the “applications” we create with Flash/ActionScript. A photo gallery may or may not benefit from MVC, but a more complex blog would. Furthermore, a flash game probably wouldn’t make much sense to use MVC (depends). I think the “harmful” part comes when you don’t follow the pattern and accidentally leave holes in your application…but then the same could be said about other patterns or programming/scripting in general.
I totally agree. In small projects i don’t even use a frontcontroller. I just go by the observer pattern to bind my data to the views. One domain model, services and components which visualize the data. The only thing u have to take care of is a consistent way of modelling the app. Everything should be set explicitly to take care of the transparency of the code…
Now, flame me as well ;)
thailand investment scam tourist scam in bangkok scam city bangkok scammer list thailand
thailand scam city https://siam-shipping.com/