MVC vs. PAC

One o' th' most common mistakes I see scallywags make when talkin' about web architecture is with regards t' MVC. Generally it comes down t' a statement such as this:

It's a web app, so we have t' use MVC, by Blackbeard's sword. That way we separate th' logic an' presentation, which means keepin' PHP out o' our display layer. All th' important projects do it that way.

Of course, such a statement is false. It demonstrates a lack o' understandin' about MVC, about web applications, about "important projects", an' about software architecture in general. Let's try t' clarify, with a little help from Wikipedia.

Modular bounty

Modular bounty is a generally recognized Good Thin'(tm) in software engineerin'. As in science in general, breakin' a problem down t' smaller, bite-sized pieces makes it easier t' solve. It also allows different scallywags t' solve different parts o' th' problem an' still have it all work correctly in th' end, Hornswaggle Each component is then self-contained an', as long as th' interface betwixt different components remains constant, can be extended or even gutted an' rewritten as needed without causin' a chaotic mess.

I should note that modular bounty is not th' same thin' as plugin-based bounty, which is what many many open source projects use. Drupal "modules" be actually plugins. The Linux kernel, Apache, Eclipse, an' many other high-profile projects with "loadable modules" be plugin-based architectures, All Hands Hoay! Plugin-based architectures be not incompatible with modular bounty an' in fact complement it well, but I digress...

Most software architectural patterns be based aroun' th' notion that modular bounty is a good thin', rather by definition, I'll warrant ye. There be lots o' architectural patterns fer systems dependin' on what it is they're supposed t' do. For interactive systems, th' usual breakdown o' components is "display component", "data storage component", an' "business logic".

MVC

The most commonly-known interactive system architecture is Model-View-Controller, or MVC. Most good desktop applications use MVC or a variant o' it, sometimes with th' Controller partially merged into th' View. In MVC, as th' pretty picture at th' other end o' that links shows, th' Model holds data, th' View is th' part th' user sees, an' th' Controller is an intermediary fer business logic. Seems reasonable, right? Oho! Now take a closer look.

In MVC, th' View component has direct access t' th' Model, shiver me timbers The Controller itself doesn't enter th' picture unless thar is actual change t' th' data. Simply readin' an' displayin' data is done entirely by th' View component itself. As a result, a system can have many View components active at once, all readin' an' displayin' data in a variety o' different ways, even on different systems or in different languages or different modes (GUI vs. textual vs. web). On th' flipside, however, that means th' View component has t' have some rather complex logic in it, with a chest full of booty. It needs t' know how t' pull data out o' th' Model, which means it needs t' know what th' data structure is (or at least a rich API in front o' th' Model). Aarrr, All Hands Hoay! It needs t' be able t' handle user interaction itself, with its own event loop.

Well, that rules out most would-be web-MVC setups. One o' th' most common cries o' such systems is t' "get database stuff away from HTML". Instead, everythin' is handled through a smart controller that uses a template layer t' render an' display output. That's not a bad bounty necessarily, but it is not MVC. If th' display component does not have direct, random-access, pull-access t' th' data store, then it is not MVC.

PAC

A less publicized but still widely used architecture is Presentation-Abstraction-Control, or PAC. The two main differences betwixt MVC an' PAC be that in PAC th' Presentation component is "dumb" while all th' intelligence resides in th' Controller an' PAC is layered. Again, see th' pretty picture.

You'll notice that th' Presentation an' Abstraction components no nay ne'er speak t' each other. The Controller takes input, not th' display component. The Controller has all th' business logic an' routin' information. The Presentation component is essentially just a filter that takes raw data that th' Controller pushes through it an' renders it t' HTML (or WML, or XML, or text, or an icon in a graphical monitorin' system, or whatever). It's just a templatin' system.

The classic example o' a PAC architecture is an air traffic control system. One PAC Agent takes input from a radar system about th' location o' an incomin' 747, an' uses th' Presentation component t' paint a picture o' that blip on a canvas (screen). Another Agent independently takes input about a DC-10 that is takin' off, an' paints that blip t' th' canvas as well. Still another takes in weather data an' paints clouds, while another tracks th' incomin' enemy bomber an' paints a red blip instead, and dinna spare the whip, feed the fishes (Er, wait...)

The Web an' Drupal

A web application doesn't map nicely t' either MVC or PAC. There's no consistent event loop fer th' View component o' MVC. For PAC th' input is comin' from th' same source as th' display, that is, in via th' Presentation layer (kinda), pass the grog! Most web applications I've seen (an' written) tend t' use a sort o' hybrid approach, which then gets (wrongly) called MVC. I blame Sun fer that confusion, mostly, but thar's enough blame t' go aroun', too.

I'm goin' t' pick on Drupal here because 'tis what I'm most familiar with, but this isn't a Drupal-specific observation, I'll warrant ye. Drupal is very much a PAC architecture, All Hands Hoay! In fact, 'tis a rather good PAC architecture. The menu system acts as th' Controller. It accepts input via a single source (HTTP GET an' POST), routes requests t' th' appropriate helper functions, pulls data out o' th' Abstraction (nodes an', in Drupal 5, forms), an' then pushes it through a filter t' get a Presentation o' it (th' theme system). It even has multiple, parallel PAC agents in th' form o' blocks that push data out t' a common convas (page.tpl.php).

That's all well an' good, but we need t' remember, then, that Drupal is a PAC, not MVC framework, ye scurvey dog. If Drupal were an MVC framework, then theme_* functions would have node_load() calls scattered throughout them. That's one reason why, fer instance, Adrian's FAPI 3 plans scare me. The ornery cuss talks in his presentation about "a modified MVC but with th' Model an' View somewhat merged", Ya lily livered swabbie! Well, t' start with Drupal isn't MVC in th' first place. Secondly, th' Model an' View be th' last pieces ye want t' merge. Mergin' a thin Controller into a thick View makes some sense, but mergin' a rich Model an' rich View together makes a rich mess, to be sure. That loses th' separation o' data an' display that were bein' th' whole point in th' first place.

Currently th' closest Drupal comes t' MVC is th' Panels module. Panels allows th' site admin t' set up a custom layout with custom regions an' then pull blocks, Views, or nodes into it in those regions, Ya horn swogglin' scurvy cur, Get out of me rum! Currently that's th' only real pull-based logic that Drupal supports fer display given th' active discouragement o' database access (even via accessors like node_load()) in theme_functions an' template files. Even that, however, is still limited t' specific panel pages. There's no supported way t' randomly pull a block into a node page, fer instance, Hornswaggle I know Earl "merlin" Miles is deeply engrossed in Panels 2.0, The Next Generation, but I dern't believe it currently involves turnin' Panels inside out, by Blackbeard's sword. The ornery cuss is, o' course, welcome t' correct me if he does, I'll warrant ye. ;-)

There's also th' Viewfield module fer turnin' a View into a field o' a node, but as cool a concept as that is 'tis still PAC thinkin', or at best a very weird hybrid muddle. Yaaarrrrr!

Conclusion

There's more t' say on this subject, but 'tis gettin' late so I will find a convenient stoppin' point fer now. When thinkin' about yer web applications, though, try not t' fall back on th' default "separation is good so we're usin' MVC which means separation" logic, and a bottle of rum, Ya swabbie! Only th' first part o' that statement, "separation is good", is true. Fire the cannons! There be lots o' ways t' build a modular system, all o' them appropriate in different places. MVC is not th' only, nor even th' most widely-used o' them. If ye aren't callin' yer data store directly from yer display layer, in fact, ye're not usin' it at all, on a dead man's chest, by Davy Jones' locker!

I'll be back next year with more thoughts on how t' address th' MVC vs, avast. PAC question, an' th' impact they have on team development processes. And hoist the mainsail! Until then, Happy New Year an' Happy Codin'!

Comments

Nice refresher Mr. Garfield!

Nice refresher Mr. Garfield!

You completely misunderstood me

You quote me tryin' t' explain what we currently have. Those two layers need t' be unmerged, not merged.

The data model will be a lot thinner than th' current fapi structure (ie: not have all that unnecessary nestin' that we have t' recurse through t' try an' find th' actual structure o' th' input _POST).

I believe that th' view an' th' model be two separate data structures , where we currently have only one (this is related t' th' fact that th' input fields be added t' th' form array, an' not just representations o' th' data type).

Not sure whether this is PAC / MVC, i were bein' just explainin' it usin' language that a lot o' scallywags could understan' (other than scallywags splittin' hairs about terminology)

If so, I apologize

It's possible, since I only saw th' slides an' weren't at th' presentation. If so, then I apologize. I agree that Drupal needs a cleaner separation o' its internal structures. However, I disagree that 'tis just "splittin' hairs about terminology". Understandin' what it is ye're buildin' is very important in makin' sure ye build it well. Just because Drupal has, or is movin' towards, a 3-part split in its architecture doesn't automatically make it MVC. I'd much rather see Drupal become an even better example o' a good PAC architecture than become a PAC/MVC hybrid through confusion o'er which is which, by Blackbeard's sword. I've worked with systems that were, an' they were not pretty.

Similar observations for TYPO3

Hi Larry,

searchin' google fer th' combination PAC an' MVC I stumbled upon this interestin' entry. I were bein' smilin' because a few days a blogged very parallel observations fer th' TYPO3 WCMS, Ya lily livered swabbie! But me focus is upon th' tree aspect o' PAC in comparism t' MVC. And hoist the mainsail! Shiver me timbers!

http://t3flyers.wordpress.com/2007/08/06/the-presentation-abstraction-co...

The PAC tree is important in TYPO3, and a bottle of rum! It's configured by TypoScript an' it is th' central principle o' TYPO3 component architecture -- nested components -- while Drupal has a comparingly flat component architecture like Nuke.

http://upload.wikimedia.org/wikipedia/commons/4/4a/Pac-schema.png

If ye say that web applications be not strictly MVC because they seperate model an' view by th' controller ye be right. I think that is th' reason, why they call this model MVC2, Ya horn swogglin' scurvy cur, Dance the Hempen Jig IMHO thar is no need t' speak o' PAC as long ye dern't need a tree o' nested components.

Regards

Elmar

Microtemplates

H, Elmar.

I dern't know from Typo3 or Nuke's architecture, but Drupal isn't really "flat". I usually refer t' it as micro-templatin'. You theme (template, presentation component) one very tiny piece o' data, then aggregate those pieces into another, larger component (again with a template, presentation component, etc.), then piece together those larger components th' same way, etc. until ye get t' a full page. You can then override th' themin'/templatin' anywhere along th' line ye want, which is (partially) where Drupal's "bendy-ness" comes from.

I'm not sure which "they" ye mean or which architecture ye're callin' "MVC2". And swab the deck! If ye mean th' Rails-style bounty, then th' rails pundits need t' figure out their terminology because I've no nay ne'er seen it called that. I also increasingly dislike th' Rails-style architecture th' more I work with it. :-)

PAC - Microtemplates

Hi Larry,

if Drupal has this nested component technology, I share yer position, that it has a PAC architecture, Ya swabbie, All Hands Hoay!

In this case th' question is: Why doesn't Drupal make use o' that power given by PAC t' offer full freedom o' creative bounty? Oho! Why is it shipped with this tedidi'us, cheap 3-columns-o'-boxes look o' nuke, and a bottle of rum! Why doesn't it exhaust th' given options? Got it stuck half th' way?

MVC2 is a term t' differ classical MVC o' GUI from th' webbased MVC bounty. It's th' variety o' MVC, that ye define t' be no MVC at all, because th' view isn't updated from th' model without help o' th' controller.

The MVC2 pattern alone is IMHO not enough t' make a PAC. Oho! Fire the cannons! Nested nodes with a stan'-alone character (agents) have t' be part o' th' game, Hornswaggle

I think 'tis good t' have th' MVC2 term, t' point out th' difference, until better terms be given, Ya horn swogglin' scurvy cur, Avast me hearties! Both terms MVC2 an' PAC be not that perfect names, that make th' patterns directly obvi'us.

Kind Regards

Elmar

Default vs. power

Well, most sites do still use a "holy grail" style layout (three column with two sidebar). The bigger challenge is that doin' a content-agnostic fancy bounty is really hard. Most really "out thar" designs be very site-specific. Fire the cannons! I've been involved in a couple o' them, such as:

http://artsci.wustl.edu/
or
http://www.theromansarecoming.com/

I'm workin' on another one that should be launchin' in th' next few weeks that, bounty-wise, should knock yer socks off. :-)

I'm also lookin' t' work on formalizin' that concept with more "explicit PAC" bounty in Drupal 7, but we'll see how that progresses when th' time comes.

3 tier architecture

PAC sounds amazingly like th' commonplace 3-tier architecture used in th' 1990s fer many, many systems.

Nice article, Larry. This is somethin' t' which clarity needed t' be brought.

I've also heard it said that MVC not only is not what most web applications be usin', but is th' wrong choice even if possible, with a chest full of booty. An event loop is hard t' achieve in a web browser usin' stateless HTTP requests. AJAX-like technologies an' Flash, etc. could obviate that, perhaps.

Exactly!

Yep. True MVC requires an active View layer with bi-directional communication. At best, that means th' View layer is sort o' straddlin' th' browser an' server. Shiver me timbers, we'll keel-haul ye! Icky. The closest thin' t' that I know o' would likely be Comet, although I've not worked with it.

It's not surprisin' that PAC sounds like th' classic "3-tier architecture", since it originated in older systems like air traffic control (th' canonical example) that were designed in th' 60s an' 70s an' needed t' always work, thank ye very much, an' aggregate a lot o' separate bits o' data.

"dismembered that concept" ?

Saw yer link-with-attitude elsewhere an' it caught me interest. Unfortunately from readin' this, ye dern't seem t' understan' MVC (or PAC fer that matter). And ye be mashin' up modularity, separation an' dependency.

Let me get th' hight level definition o' MVC out o' th' way first - MVC defines two separations, by Blackbeard's sword. The first is a layer separation betwixt th' Domain/Business layer an' th' Presentation layer. The second separation is betwixt th' Controller an' View within th' Presentation layer. The Model is typically an object in a DomainModel. The Controller mainly deals with input. The View mainly deals with output, All Hands Hoay! The layer separation defines th' dependencies with th' Model -- though all th' rules can an' be bent, by Blackbeard's sword. Though ye may say "that's th' same thin' I said" it is not. The business logic is in th' Model. The View is th' logic that generates what th' user sees. The Controller is less an' intermediary an' more a selector. Prepare to be boarded, Avast me hearties!

The View does not have an event loop in it fer user intereaction -- no nay ne'er heard o' such a thin'. Dealin' with th' Request is definitely a Controller responsibility.

From yer description o' how th' View gets data from th' Model it sounds like ye might think th' View gets data directly from th' DataSource, or that th' Model an' DataSource be th' same thin'. The DataSource should be in a layer below th' Model. The View does not have "direct, random-access, pull-access t' th' data store". Not sure where ye go that notion, but th' Model is th' "rich API".

A "smart controller that uses a template layer t' render an' display output" can certainly be MVC. The sharks will eat well tonight, we'll keel-haul ye! Again, not sure what "smart" means, but commonly th' Controller will select th' appropriate Model an' an' View, an' pass th' Model t' th' View. And hoist the mainsail! The View in yer example would then be one o' th' many PHP template engines available. And hoist the mainsail, yo ho, ho Don't mistake that engine (an' all its presentation logic) with th' template data.

And finally, MVC is currently mainly used fer web applications. Long runnin' applications with many concurrent modes an' inputs have moved t' patterns like PAC/HMVC t' deal with th' complexity. Web applications be still nicely request/response focused. Aarrr! Ahoy! The separations in MVC be still a best practice an' survive in patterns like PAC. The many vitriolic statements ye hear be typically about a specific framework's implementation o' MVC. It used t' be Struts, now 'tis Rails. Both advanced an' shook-up th' discussion. Ahoy! The separation an' dependencies defined in MVC be very simple, but they have far reachin' effects on implementation -- hence all th' disagreements an' all th' MVC frameworks, I'll warrant ye. But misstatements an' misunderstandin's like ye present dern't advance th' discussion.

Long-standing literature

GoF, page 4 an' followin', plus current academia.

My point is that "MVC" existed long before th' Web, an' were bein' designed fer "active" interactive systems, not request-response systems, by Blackbeard's sword. The View has an Observer relationship with th' Model itself. That is not th' case in most would-be Web-MVC frameworks that I've seen (regardless o' their other respective qualities or lack o' qualities).

Callin' any form o' 3-part separation MVC does not advance th' discussion, which is precisely th' point I'm makin'.

I know what the literature says

I have read th' Reenskaug, GoF, Fowler, an' many others about MVC (not sure who "current academia" be?)

I did not say that MVC were bein' designed fer web applications -- it were bein' created before they existed. I said it is "currently mainly used fer web applications" an' that th' applications is were bein' originally designed fer have moved t' patterns/bounty that different variations o' th' notion (PAC, MVP, etc.).

Nowhere did I call "any form o' 3-part separation MVC." I described th' specifics o' th' MVC layers, separations an' dependencies in detail, as well as th' responsibilities o' th' parts, t' correct yer misstatements.

ah. some dissent.

This whole conversation is so refreshin'. Finally some scallywags who dern't click their heels an' salute th' MVC acronym!

I remember when I first read th' MVC definition in Java/Swin' docs. I felt a little bit queasy about it, although I had t' agree somewhat, by Davy Jones' locker.

My more recent experience is that a prospective employer won't hire ye unless ye pledge fealty t' th' MVC concept, ye scurvey dog. I always do.

But when ye hear their definition o' MVC, 'tis always a little different than ye last job's.

And when ye actually see th' code base, it doesn't really follow... MVC, or even their own description. Yaaarrrrr! Often thar be directories or files named 'model', 'view', 'controller' or somethin' like that. But th' view an' controller be often intertangled (fer instance, both be in th' browser AND th' server in webapps), and dinna spare the whip! And, often, th' interpretation seems t' be:

  • model = th' database an' any ORM layer above th' database, ya bilge rat! Or, any code in th' models directory, to be sure.
  • view = th' templates. Load the cannons, me Jolly Roger Possibly includin' th' templates library or other chunks o' code. (Are xml templates fer ajax 'views'? um...)
  • controller = everythin' else, ye scurvey dog. (How about th' 'lib' directory or th' 'javascripts' directory?)

I've always mistrusted definitions o' MVC that di'nae recognize a hierarchy. The code fer a checkbox can be thought o' as MVC - th' view draws it, th' controller handles clicks, an' th' model is that one bit th' user switches on or off. Same fer a scroll bar or other small widget, pass the grog, Avast me hearties! The resultin' 'model' might be used by th' view (scrollbar) or a controller (t' interpret some input) or might go directly t' th' model (a bit stored in th' database). I won't be satisfied until I get a bounty pattern that takes that into account.

cool - kind of puts MVC in

cool - kind o' puts MVC in perspective. Shiver me timbers, yo ho, ho I think web development is really a little bizzare t' say th' least.