More on Cognitive Load – The Rendering Tier

Dietrich Kappe, Monday, August 7, 2006 @ 12:19 pm

In a comment to my post Friday on cognitive load and the supperiority of server-side AJAX GUI frameworks, reader Matt took me to task for muddling my tiers:

I would argue that mixing the middle tier (java) with the front-end (javascript, html, css) is the same as mixing the middle tier with the backend (db). In general, it is bad practice. Sure, some companies still directly access the db from inline sql, but the majority of developers agree it is bad practice.

While I agree with Matt that if you're going to adopt a layered architectural approach, you don't want to mix different subtasks into the same layer, simply putting code into the same physical environment or writing it in the same language does not constitute mixing layers. Rather than blindly following the "tiered approach," it is helpful to look at the original patterns source and understand its purpose. The first time I saw a formal discussion of the layered architecture pattern was in 1996 in the very useful Pattern-Oriented Software Architecture: A System of Patterns, Volume 1 by Frank Buschmann et al., Chapter 2, Section 2.2: From Mud to Structure. (Funny how some patterns in that book gained huge popularity, such as MVC, while more elegant patterns, like Presentation-Abstraction-Control, gain barely a mention.) From the text:

The Layers architectural pattern helps to structure applications that can be decomposed into groups of subtasks in which each group of subtasks is at a particular level of abstraction.

[snip]

The main structural characteristic of the Layers pattern is that the services of Layer J are only used by Layer J + 1-there are no further direct dependencies between layers. This structure can be compared with a stack, or even an onion. Each individual layer shields all lower layers from direct access by higher layers.

[snip]

Specify an interface for each layer. If Layer J should be a 'black box' for Layer J+1, design a flat interface that offers all Layer J's services. and perhaps encapsulate this interface in a Facade object [GHJV95]. The Known Uses section describes flat interfaces further. A 'whitebox' approach is that in which Layer J+1 sees the internals of Layer J. The last figure in the Structure section shows a 'gray-box' approach, a compromise between black and white box approaches. Here Layer J+1 is aware of the fact that Layer J consists of three components, and addresses them separately, but does not see the internal workings of individual components.

Good design practise tells us to use the black-box approach whenever possible, because it supports system evolution better than other approaches. Exceptions to this rule can be made for reasons of efficiency, or a need to access the innards of another layer. The latter occurs rarely, and may be helped by the Reflection pattern, which supports more controlled access to the internal functioning of a component. Arguments over efficiency are debatable, especially when inlining can simply do away with a thin layer of indirection.

The first observation I have is that writing our code all in Java still allows us to adopt a layered approach. The UI code can be nicely abstracted from the business layer, as people have been doing now for decades. Just because we are writing both in Java doesn't mean we are mixing the tiers.

The second observation I would make is that there is some confusion over which is the highest tier in web applications. As it's usually illustrated in architectural diagrams, the presentation tier sits on top. Certainly that's the way the end user sees it, and you can make an argument that that is how interactive applications should be architected, with the presentation tier using the services of the next tier down. I'd suggest a further refinement, one that's been creeping into web applications and various frameworks: the rendering tier. That's where the details of the underlying user interface device are abstracted as a set of functions for use by the presentation tier. That's precisely what Echo2 does, hide the details of HTML, Javascript, CSS, etc., in a rendering layer.

Although no other rendering implementations exist at present for Echo2 and ZK (another server-side framework), they are perfectly positioned to add support for Flash, mobile, desktop and other user interface devices.

So, my response to Matt is that we aren't mixing layers here, but -- staying true to the original intent of the architectural pattern -- improving the design of web applications by abstracting the details of the browser into a lower level rendering tier.

Technorati : ajax, cognitive load, complexity, layered architecture, patterns

Related posts:

1. Cognitive Load and the Superiority of Server-Side Ajax GUI Frameworks
2. Cognitive Load in Java Programming
3. Cognitive Load, Portability and the Superiority of Client-Side Frameworks
4. Useful Guidelines for Ajax Developers
5. Using Design Patterns

Comments (0)

Software Development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment