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 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".
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.
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...)
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!
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'!