AJAX, MVC, and SIM
From Zanecorpwiki
In process of major rework.
Rework thoughts: change article title to 'Systems Construction', pull out/mold thinking of software beyond code; rename existing article 'System Design and Code Blocking'; current narrative is story of process of how my perception changed; my internal conflict reads somewhat like MVC vs. SIM; better narrative is SIM has advantages over MVC; pen and tie in article on building applications from local services; http://pragdave.pragprog.com/pragdave/2007/03/the_radar_archi.html; http://www.littlehart.net/atthekeyboard/2007/04/27/fat-models-skinny-controllers/
I've been telling people for some time now that I love AJAX style programming because aligns so nicely with MVC. I haven't got a lot of traction with this view, which I found curious, because to my mind it seemed so natural and obvious. I've come to realize that my view is informed by an uncommon breadth and depth of experience. AJAX is not obviously aligned with MVC. Indeed, to some, the two are antagonistic.
Contents |
A Brief History of the MVC
MVC was developed in the context of 'client/server programming', which is now-a-days dominated by web programming. The problem was how to organize a system in the client/server environment. The solution was to divide the system into three parts: the model, the view, and the controller.
Model refers both to the data model itself, and the state of the running system. In practice, this means database tables and their contents, files and their contents, and other system state.
View means what the user sees. This most often means a human user, but it it encompasses other systems that may interact with the system. The view is outside of the black box of the system.
Controller means the logic or control code. With many systems, it is popular to say that the controller is the embodiment of the business logic. More broadly, the control defines the flow of control through the system as well as the part of the system that changes state.
The issues MVC fundamentalists have with AJAX revolve around Javascript as part of a dynamic view. In AJAX apps, there is almost always some kind of client side data verification going on. Quite often, there's client side flow control of one kind or another. In general, the view is dynamic and reacting to user input without the involvement of the traditional control.
When such systems are built using straight AJAX (i.e., without frameworks), then one ends up with data checking and/or flow control code next to view code. Since MVC is all about organizing code structures, this, it is argued, breaks MVC.
In my estimation, this view--that AJAX and MVC are antagonistic--is somewhat circular in nature. If one looks at the history of MVC, it is a history of frameworks. For most developers, MVC is inextricably linked with frameworks. I would even go so far as to argue that it would be impossible to realize a strict MVC compliant system without the use of frameworks.ref group=notesThis statement is very much dependent on one's definition of 'framework', for which there is no strong 'common definition'. However, since client side data checking will always bring model constraints into the view, and client side flow will bring control aspects into the view, these observations strongly imply a framework-like implementation must be involved./ref
This makes sense as the MVC was conceived when frameworks where very much the next big thing. (Modern) Frameworks and the MVC grew up alongside each other. In other words, the classic MVC is a structural organizational system that fundamentally pre-supposes the use of frameworks. Thus, it is neither surprising nor useful to say that a non-framework AJAX implementation breaks the MVC.
Javascript and the MVC
Javascript can be used in an MVC framework. There are in fact many frameworks that do just that. Rather than write code to check data constraints, these frameworks define a quasi-language of some sort wherein constraints can be defined. Through some sort of compilation or dynamic scripting techniques, these definitions are pulled into the client side Javascript and effect the constraint on the client end.
I have the same problem with these frameworks as I do with frameworks in general. Not that they're bad, but they're not my thing. It's both an aesthetic reaction, and an assertion that frameworks are generally not appropriate for the kind of development I do.
SIM
The spirit of the MVC is about good organization of code. For the reasons discussed above, straight AJAX does not fit well with MVC organization. That's not a problem, it just means AJAX style code needs a different organization.
Enter SIM. AJAX grew up alongside the development of the idea of service oriented architecture. The AJAX/Web 2.0 culture is very closely related to the service architecture concept. Thus services-interface-model.ref group=notesI like 'MIS' a little better, but that clashes with 'management information systems'. Not entirely convinced SIM is the way to go, but I'll use it for now./ref
The model in both SIM and MVC is the same thing. It's the data structure and state of the system.
The interface in SIM is conceptually quite different than the view. The MVC idea of a view is that of a static presentation produced by the interaction of the model and controller. The view is a mapping of state into presentation. It may present controls, but those controls are all implemented in the model, the view itself does not do anything.
In SIM, the interface presents a view, and is directly responsible for flow control, which is part of the responsibility of the controller in MVC. In other words, with MVC, clicking a link results in a request back to the controller. The controller then generates a new view. In SIM, controls, such as links, may link to a service (when they involve state change), but flow control decisions are handled directly by the interface. If there is no state change involved, then there may not be any call to the server at all.
Compared to the MVC, services are the other half of the controller. I.e., in MVC the controller actually did two things: it controlled flow and updated state. In SIM, the interface controls flow, and the services update state.
SIM is a Conceptual Model
Setting aside the differences in boundaries, there is another almost cultural difference between the MVC and SIM conceptions. MVC is a conceptual model that very much wants to reflect that model along hard lines in the code. Mixing expressions from the model and view, or control and view, etc. is considered a no-no. Hence, the effective requirement that a framework of some sort be used to effect this separation.
This kind of hard/implementation separation is certainly possible with SIM, but it's not required to be SIM compliant. In effect, this means that I wouldn't get bent out of shape about expressing data constraints in the interface code. It's true that such constraints could be factored out into some sort of framework or library, but if they're not, it's not that big a deal.
Factoring out such constraints is a good thing in-and-of-itself, but if the cost of doing so is higher than the gain (which it can easily be), then don't do it. Everything succumbs to dogma, but here at the beginning at least, let's not hasten the process by subjugating our best development to arbitrary dictum.
Besides, what's more important than repeating or mixing code is actual control. Client side checking should always be viewed as a convenience, not a control point. A best practices data model will define and enforceable constraints. Best practices services, responsible for changing the state, should do their part as well, verifying authorization, authentication, etc.
In other words, the important part of the conceptual model is not code separation, but responsibility separation. When the two match up, all the better, but let's not lose the forest for the trees.
Design vs. Evolution
Personally, I find the ideas of the service oriented architecture and the MVS much more appealing than those of MVC. I always liked the idea of system structure that MVC proposed, and when it was really the only game in town, I was a big proponent of MVC and have oodles of experience with it.
The MVC was a first stab, had lots of good ideas, but to my mind, it's time to move on. MVC is both itself and heavily associated with a design heavy culture that in practice always ends up being a bit arbitrary and stiff. My experience with MVC supports this. The systems quickly become stiff and somewhat inflexible. They begin to feel arbitrary in nature.
SIM, on the other hand, arises from and supports a much more organic, evolutionary approach to system design and construction. This not only feels more natural to me, but I believe allows the development of superior systems.
SIM itself is an example of this. Javascript was not designed as part as a service oriented approach to developing websites. People figured out how to use it for those purposes, however, and found that it worked very well. The language has adapted to better support such a style in development just as the style of development itself has evolved. Perhaps there is a synergy that develops in this kind of mutual evolution that is simply lacking in the top down design process that is at the root of historical MVC and related frameworks.
Aesthetics of SIM
I always felt that the controller was bloated. This is an aesthetic statement, but easily understood. Look at any MVC system and a good 80-90% or more of the actual code is controller related. The controller does everything by definition since both the data model and the view are static in nature.
Because the responsibilities are more evenly spread between the parts, SIM systems are, to my mind, more balanced. The various parts of the system share the burden.
Even more important, and in the end the most appealing aspect of the SIM, is the idea of federated systems. In theory, federated systems are entirely possible with MVC and some MVC systems and concepts are very closely related or in fact directly strive for federated systems. In practiceref group=notesHere I am drawing on both my personal experience and my general awareness of developments and thrusts in the larger arena of software development./ref however, SIM systems--especially as they relate to service oriented architectures--do a much better job of effecting federated systems. In the end, a SIM approach is probably better than MVC for federated systems, but the real advantage may be primarily cultural in nature.ref group=notesCultural advantage often leads to concrete advantages in tools and processes, however, so don't take this as a soft advantage. It's very real./ref
Dividing Work
One of the ideas behind the MVC view was the separation of look and feel from any coding. In the ideal MVC, after after defining the program flow, one would have a list of pages which could be handled entirely by developers. Fields or other dynamic portions of the view would then be swapped out for tags. If this was done through a templating engine that the designer was familiar with and which could support mock-ups, it would even be possible for the web designer to produce actual view code directly.
In my experience, this ideal was never realized. In the early days, it was mostly a failure of the templating language to support mock-ups. With dynamic sites (involving Javascript), the implication that MVC requires a framework also means that the interface itself is harder to develop without some knowledge of coding.
SIM has this same weakness, in that the interface contains control widgets that render elements of the final view internally, and as such are not naturally accessible to web designers. This isn't a weakness of SIM, so much as it is a cost of developing a highly dynamic/Javascript style application given current approaches and capabilities.
In other words, the original MVC definition took cognizance of rolesref group=notesRoles was a hot topic at the time MVC was emerging as the new hotness. One can also see this in the Enterprise Java movement, which is lousy with roles./ref and MVC was, in part, defined with the explicit idea of hard separation of web designer from coder. This aspect of MVC is in conflict with Web 2.0 in general, and though it's possible to do Web 2.0 in an MVC fashion, the hard separation of roles is difficult to maintain.
SIM starts from the idea of Web 2.0/dynamic/Javascript sites, so doesn't attempt to define roles in the same way. Thus, SIM avoids the conflict even though there is functionally no benefit on this point.
In my experience, roles don't really work (at least not in the way that MVC and contemporaneous movements thought they would). MVC has some baggage here, in-so-far as practitioners sometimes project the imagined benefits of roles into MVC even while it may be no longer possible, practical, or desired to divide work along those lines.
As far as I can see, the roles movement was an interesting idea that didn't go anywhere because it turns out to not work very well. While the theory sounds good, in practice, there are better approaches.
With a roles/MVC approach, work was divided by type. Database guy made tables, interface guy made view, and developer guy made controller. They might all meet from time to time to discuss the application and how each role interacts, but on the whole the goal was to divide and conquer and the MVC's approach to artifact blocking, as well as the dominant culture, encouraged arms length interaction through well defined interfaces.
With SIM, the natural division of work is across function. Rather than the large horizontal domains of MVC, the SIM approach is much more vertical. There are still definable roles within tasks, but collaboration is around tasks rather than roles. In other words, in classic MVC, roles beget tasks. In SIM, tasks beget roles.
Other Views
Blurring of MVC lines: Programming the Web Browser. Makes some good points, that have informed my own phrasing. Overall, I don't find his arguments persuasive. He starts from the idea that frameworks are the way to go and with a rigid conception of MVC that I find distasteful.
TODO: link others.
Notes
references group=notes /
