Email Password Remember me?  Lost your password?

Introduction

Logical layers within n-tier systems should be designed to interact and be influenced by neighboring layers only. This restriction is often violated, which is detrimental to the system. In this article I will discuss why this is so common, its consequences and why we should focus on layer isolationism.

This article focuses on concepts and presents a detailed discussion. Future articles with detailed examples will be built on this article. This article is built on the concepts that were discussed in "Dude, Where's my business logic?"

Physical tiers

For comparison purposes, let's first consider how physical tiers are related:

In this example a 3-tier system is represented. Each tier can only communicate with neighboring tiers.

Direct access from the client tier to the storage tier is not permitted because they are not neighbors. Most developers don't even consider trying such a hop. However in this article I will show you how developers perform the same offence with logical layers often without even recognizing it.

Tiers of layers

The terms tier and layer are often used interchangeably. When I use tier, I am referencing a physical layer. When I use layer, I am referencing a distinct software layer. Layers must exist on a tier, and thus tiers contain layers.

Layers are not bound to tiers. In fact in the next two diagrams you can see that the business layer can move between tiers in different deployment scenarios. Not all layers are mobile, but many are. Deployment scenarios depend on the network topology and other factors.

Business Layer on Storage Tier

Business Layer on Client Tier

Logical Limbo

For discussion I will use three layers, although many n-tier systems have more. Normally each of these layers has sub layers. Each layer should communicate and depend on its neighboring layer, and only its neighboring layer.

When placed on tiers, often at a high level it becomes a 1:1 relationship.

This is how we think about logical layers, and if only the interface connections are considered, this is an accurate depiction. With logical layers we need to consider not only the interface connection but also the interface design, influences, and other constraints. These are the phantoms of logical layers that are overlooked, or often not even recognized.

This is the most common implementation. The presentation layer has no physical connections to the storage layer, but the two have been designed around each other and tangible compromises have been made because of the constraints imposed by the other.

The situation becomes more apparent when the layers are repositioned to better show the relationships. Instead of a clear front to back system, it is clear that it is actually a circular system.

I have represented the layers in a high level overview. Each layer however has additional sub layers.

When typical logical links are added, you can see the clear violation of the "neighbor access only" rule.

In some cases, not only is the rule violated for logical links, but physical links are established as well that jump neighboring layers.

Such systems are extremely brittle and very difficult to upgrade, expand, or debug. For any layer to be worked on, a developer must be a "Santa Developer". That is, he should see everything, good and bad across the whole system.

By removing the tiers and rearranging the positions of the layers in the diagram, the pattern that has been created can be more easily seen. It's obvious that not only the layers are over stepped, but that a spider web is created.

Patterns

Storage layer driven pattern

Using a storage layer driven pattern, the storage layer is first designed and then the presentation layer is designed around the storage layer. Once this is completed the business layer is designed around the storage layer, since the presentation layer has been designed around the storage layer. This causes artificial constraints in the presentation layer and limited transformations in the business layer. Result sets returned from the business layer are typically restricted to simple transforms that can be executed by SQL queries or stored procedures.

This pattern is extremely common because it is similar to the traditional client server development and to the systems designed around the existing databases. Because the presentation layer is designed around the storage layer, the presentation layer often mimics the actual structure of the data in the storage layer with unintuitive screens.

Very often there is an additional feedback cycle from the presentation layer to the storage layer. The feedback cycle occurs when something cannot be retrieved in a format convenient to the presentation layer. The developer then requests changes to be made in the storage layer for the benefit of the presentation layer, but which is detrimental to the storage layer. These changes are artificial and without such limitations is otherwise not necessary. These changes often violate or at least strain the proper precepts of database design, cause unnecessary data duplication and denormalization.

Presentation layer driven pattern

Using the presentation layer driven pattern, the storage layer is designed around the presentation layer. Implementation of the business layer is typically fulfilled by simple SQL queries and does little transformation or isolation. Databases are poorly designed and suffer from performance problems as they were primarily designed for easy access by the presentation layer rather than using normalization and other storage layer concepts.

Isolation driven pattern

Using the isolation driven pattern, the presentation layer and the storage layer are developed independently, often in parallel. The two layers are designed without any influence from each other so as not to introduce artificial constraints or detrimental design elements. After these two layers are designed, the business layer is designed and it is the responsibility of the business layer to perform all transformations without requiring changes to the storage layer or the presentation layer.

Because the presentation layer and the storage layer are now completely independent, either can be changed as and when necessary by updating the business layer. Changes to two physically disconnected layers do not influence or directly impact the other layer. This allows for structural changes in the storage layer or presentation layer to quickly respond to the user needs without requiring system wide changes or updates.

Comparison

Partitioned roles

Because old habits die hard, it can be very difficult for teams to adapt to the isolation driven pattern. To facilitate isolation driven pattern in teams the use of partitioned roles is very beneficial. Use of partitioned roles has other benefits as well, including faster and better development.

To prevent functions from being improperly distributed or placed in incorrect tiers, developers are assigned to a specific layer. The function of working on a specific layer is called a role.

Storage layer role

1. Creation of views required by the business layer and as requested by the developer in the role of business layer.
2. Creation of stored procedures for insertion, deletion and update of tables.
3. Review and optimization of views and submitted SQL through plan optimization, index maintenance, etc.

Business layer role

1. Creates and maintains external interface exposed to the presentation layer using web services or other remoting capability.
2. Defines the external interface for use by the presentation layer.
3. Requests views to retrieve and stored procedures to modify data from the storage layer role.
4. Implements all the data transformations between the virtual and the physical layers.
5. Creates initial regression tests for building and testing the business layer.

Presentation layer role

1. Implements the end user interface.
2. Connects the end user interface to the business layer using the interface provided by the business layer role.
3. Designs and submits virtual datasets and or other data transport contracts to the business layer role.

Role roaming

While a developer should be assigned to a specific role, developers should also roam among different roles.

Roaming among roles in smaller teams allows for better allocation of resources. Roaming in larger teams ensures that developers understand the whole system, understand the impacts of their implementations in neighboring layers, and ensures that no part of the system is affected if a developer becomes sick or leaves the company.

Roaming between roles however should not be at will and must be properly controlled. Developers should take up specific roles at specific times. If possible, a developer should not perform more than one role in the same module. That is if a system has a Customer module, a single developer should not be assigned to more than one role in the Customer module. However if a single developer works in the business layer role of the Customer module and then switches to the presentation layer role for the Vendor module, this is acceptable and allows resources to be more efficiently allocated.

This diagram demonstrates a proper example of role assignment.

This diagram demonstrates an improper assignment of roles. Both Joe and Adam have worked on two roles in the same module. Allowing such violations encourages influences and sacrifices between the layers.

The previous examples shown above were simple for demonstration purpose and only showed a single developer per module and tier. However, this is rare and in fact it's common for multiple developers to share the load. So long as none of the developers move to another tier within a given module, the guidelines are upheld.

In these examples, I have shown Pete as dedicated solely to the storage layer. This is not a rule, and in fact Pete can work in other layers. Other developers can also work in the storage layer. But typically the storage layer is handled by a DBA and only a DBA and this is why I have represented it this way.

Small teams

In small teams focusing a developer on a given role will cause resource gaps. In small teams, developers must be moved between roles more frequently as a role may be suspended when dependent items are completed. While moves are more frequent, they must still be controlled. The move from one role to another should be explicit and the move should take place only when there is no more work pending in the currently assigned role.

Tiny teams and lone developers

In very small teams and with lone developers there is no choice but to work on multiple layers in a single module. Developers should remain on one layer at a given time and only make explicit moves between layers.

A common pattern is to build each module and move on to the next module only when it is completed. This approach is acceptable:

However the developer moves horizontally in 2/3^rds of the moves. In each move if something arises the tendency is to take a step back and make a compromise, and then return:

It is often helpful to complete layer by layer instead of module by module. This isolates the layers from each other. This approach is however not always possible and requires a complete design beforehand. Some developers may also find this an uncomfortable approach and find it confusing to move sequentially between layers, but hop between modules repeatedly:

If this approach is used, note that even in this scenario two horizontal moves were performed:

If you use this approach, when moving between layers make sure to include a module movement as well. The following diagram demonstrates the best practice:

You must Sign In to use this message board.

Per page 102550

FirstPrevNext

Sample Code leoric1928 0:14 20 Apr '06   Hi, Can you please provide sample code on how to implement this one. Thanks Sign In·View Thread·PermaLink Re: Sample Code Chad Z. Hower aka Kudzu 8:29 20 Apr '06   There is no succint way to do this. To do it properly it needs to be written out as a full example system as a series of articles or a book. I'm planning to do one or the other in the future around .NET 2.0 and possibly LINQ as well. Currently I'm quite tied up with my job, but I hope this summer I'll have some more time. Thanks for your interest. A good place to keep in touch with updates is here, but also my blog at www.kudzuworld.com/blogs Chad Z. Hower, a.k.a. Kudzu "Programming is an art form that fights back" My Technical Stuff: http://www.KudzuWorld.com My Blogs: http://www.KudzuWorld.com/blogs/ Sign In·View Thread·PermaLink Fourth Option baralong 20:47 26 Jul '05   Thanks for the article, very clear and to the point. However, I thing that there was one model I think you left out: model the business layer and drive the rest from there. I've recently come from a project that used that approach quite successfully. The business objects were modelled and then the data layer was generated, the presentation layer then used the business objects, presenting as required by the user. Since then I’ve been looking at a few code generation tools and there seems to be a unnerving prevalence of taking a data-model and generating code from there. Your article has certainly added fuel to the fire against that model. Out of interest I’d like to hear how you think it stands up in the comparison. Sign In·View Thread·PermaLink Nice article marwelous 5:37 15 Jul '05   Hi, I like this article as much as the previous one. I am successfuly using Isolation Driven Pattern in my work. I found that using techniques that separate diferrent concerns into different layers enables easy understanding of the layers and sublayers even by not so skilled developers. It also enables code skeleton generation (especially domain object skeletons and CRUD data access operations generated from DB schema) because the code in the layers is very simple and in fact still the same. I realized that developers can develop whole scenario (from client, through business logic to database) especially when developing web apps, becase the web pages are well separated. But the developer must clearly understand the layers and I use occasional code review to find the code smells. I would like to say, that most of the time I tend to develop the applications in these steps: 1. Database design 2. Coding business logic and data access layer 3. Coding presentation layer It works well for me too. But it has to be said, that most of the time our analysis document contains images of the developed GUI. If there would be no such images, developing the presentation layer (at least prototype) before the business logic layer would be needed. One more question: What tool do you use for creating such amazing images and icons? Ondrej Sign In·View Thread·PermaLink 5.00/5 Re: Nice article Chad Z. Hower aka Kudzu 7:18 15 Jul '05   marwelous wrote: I like this article as much as the previous one. Thanks. Please remember to vote for the article. marwelous wrote: But it has to be said, that most of the time our analysis document contains images of the developed GUI. If there would be no such images, developing the presentation layer (at least prototype) before the business logic layer would be needed. Thats fine to prototype the GUI. Where the problem lies is when the actual GUI has to be changed from the business spec *because* of the database, etc when in reality its not necessary. marwelous wrote: What tool do you use for creating such amazing images and icons? Xara X1. www.xara.com Chad Z. Hower, a.k.a. Kudzu "Programming is an art form that fights back" My Technical Stuff: http://www.hower.org/Kudzu/ My Blogs: http://www.hower.org/kudzu/blogs/ Sign In·View Thread·PermaLink good shot Rizwan Bashir 2:59 13 Jul '05   Read your article and found it excellent or may be more.... . Though i am working on this techonology from a long time but the way you explained is Appreciate able. Made many thing conceptually clear to me. keep on writing these type of articles. Sign In·View Thread·PermaLink 5.00/5 Re: good shot Chad Z. Hower aka Kudzu 3:13 13 Jul '05   Thanks for the comments. I definitely have more articles in related themes in the works and will post them on code project, and some on my blogs. Be sure to check out my blogs to as they contain smaller snippets as well as older articles. Chad Z. Hower, a.k.a. Kudzu "Programming is an art form that fights back" My Technical Stuff: http://www.hower.org/Kudzu/ My Blogs: http://www.hower.org/kudzu/blogs/ Sign In·View Thread·PermaLink appreciation t!bast 3:02 11 Jul '05   I believe these kind of articles are the most interesting once to read, to bad they are so rare. Sign In·View Thread·PermaLink 5.00/5 Re: appreciation Chad Z. Hower aka Kudzu 3:25 11 Jul '05   Thanks. Comments like this mean a lot to authors. I have many more articles like this coming, but it takes time. Chad Z. Hower, a.k.a. Kudzu "Programming is an art form that fights back" My Technical Stuff: http://www.hower.org/Kudzu/ My Blogs: http://www.hower.org/kudzu/blogs/ Sign In·View Thread·PermaLink Where's the glue? Marc Clifton 17:22 9 Jul '05   Nice article. I've been working on an n-tier system that implements your isolation pattern, and I found the terminology and presentation in your article to be very useful. In fact, I'd like to ask your permission to use your icons and graphics for the documentation that I'm writing. If I get my client's permission, I'll post an article, and I'd be happy to reference your work (the application is a security server). However, the question remains, and this is something that nobody seems to explain, is what glues the different tiers together? Specifically, the data has to be moved/translated between the neighboring tiers. There are a lot of ways this can be accomplished--messaging, events, tiers having pointers to their neighbors, containers shared across tiers, etc. It would be really useful to have an article that describes these different approaches, and different patterns. I've been wanting to write something like that for a while, but just haven't gotten around to it. Marc My website Latest Articles: Object Comparer String Helpers Sign In·View Thread·PermaLink 5.00/5 Re: Where's the glue? Chad Z. Hower aka Kudzu 1:58 10 Jul '05   Marc Clifton wrote: Nice article. I've been working on an n-tier system that implements your isolation pattern, and I found the terminology and presentation in your article to be very useful. Thanks. Marc Clifton wrote: In fact, I'd like to ask your permission to use your icons and graphics for the documentation that I'm writing. If I get my client's permission, I'll post an article, and I'd be happy to reference your work (the application is a security server). Yes you can use them. Thanks for asking - Please just link to my article and provide attribution to me for the images/content. Marc Clifton wrote: However, the question remains, and this is something that nobody seems to explain, is what glues the different tiers together? There are many ways to glue it together. I did not want to present it here because I want people to understand the ideas etc first, and also realize that there is no *one* way, but many. I am working on some more articles that show a few ways that *I* glue things together, ie my recommended practices. But it takes a lot of time to build "useful" demos etc that are not just dummy demos and trivial. I will be presenting a standard method (ie one that is common, but I do not recommend), a more advanced one (The one Ive been using for about 10 years), and an experimental one I am working on now that is very non traditional but interesting. Marc Clifton wrote: It would be really useful to have an article that describes these different approaches, and different patterns. Its already in the works. Chad Z. Hower, a.k.a. Kudzu "Programming is an art form that fights back" My Technical Stuff: http://www.hower.org/Kudzu/ My Blogs: http://www.hower.org/kudzu/blogs/ Sign In·View Thread·PermaLink Re: Where's the glue? WillemM 10:37 27 Sep '06   This article poses the same question to me, but I think in a little different manner. I have been doing some work on an n-tier website in ASP.NET 2.0. As a "good" practice I'm using datasets for my data transportation. These datasets are send from the data tier by the business logic tier to the presentation tier. This isn't exactly isolation of tiers, because stuff that is defined in the data tier is transported to a tier that isn't a neighbour of the data tier. However, the data tier has no link with the presentation tier of visa versa, because every action on the data and every request for data that has to be displayed from the presentation tier is processed by the business logic tier. The business logic tier than validates the requests for data and executes the proper methods on the data tier. My question is: Is this the way to go, or should I keep the tiers more strictly isolated? Because, this method works, but I can't replace the data tier independently from the presentation tier, because of the datasets the presentation tier depends on. WM. Yaaarrrr What about weapons of mass-construction? Sign In·View Thread·PermaLink Re: Where's the glue? Marc Clifton 11:21 27 Sep '06   WillemM wrote: My question is: Is this the way to go, or should I keep the tiers more strictly isolated? Because, this method works, but I can't replace the data tier independently from the presentation tier, because of the datasets the presentation tier depends on. I don't think there's a good answer, because many UI controls work directly with the DataSet/DataTable, so it seems pointless to add a data representation layer that's different than the representation at the data tier (or at most, massaged by the business tier). Things get complicated though when you, say, apply a filter to a DataView. Now there has to be clear separation between the presentation layer's DataView instance and other things that may be using a DataView. On the other hand, there may be a very good reason to share a DataView at the data tier layer among different interested parties because you do want exactly that functionality--change the filter, and all the business logic/presentation layer changes. Which is why I suspect the DataView.ToTable() method in .NET 2.0 was added--so you could get an isolated snapshot of the current view. But all this still begs the question, how does the business layer manipulate the DataSet/DataTable? Do you use some sort of code generator to model the DataSet/DataView so you're not accessing fields with a string indexer? Such a thing isn't ORM, but it does bridge the abstract representation that the presentation layer works so well with and the concrete representation that you want your business layer to work with. In my Interacx[^] client/server application, the client side presentation layer works directly with a DataSet or DataView, while both client and server business logic works typically with the DataView/DataTable. However, I still have to implement some sort of code generation so the business logic on both the client and the server don't use string indexers to access the fields. Sigh. Lots to do. Marc Thyme In The Country People are just notoriously impossible. --DavidCrow There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith Sign In·View Thread·PermaLink Re: Where's the glue? WillemM 21:27 27 Sep '06   I kept my code plain and simple, as far as it kan be kept simple. I used the default wizards and tools from VS2005 to create the datasets. This means they are strongly typed, so I don't need string indexers to work with them. The manipulation on the datasets is done using the business logic layer components. Which means I have CRUD methods to manipulate the data in the datasets. The presentation layer doesn't manipulate the datasets and send them back to the business logic layer to be processed. However, the presentation layer can filter the data in the datasets. In my case I used the normal ObjectDataSource way of connecting the data to the page, which I have to say makes things simple and maintainable. All-in-all I don't think its a bad practice to use datasets the way I did in my application, but as the article already stated it's a good practice to keep an eye on the isolation of the application layers. I know for sure that if it were a different application, say one that makes use of some sort of middleware in the business tier(s) I would adhere to the isolation principles presented here, because for me its pretty clear that in the case of such an application you can't have a mixup in layers, that would be fatal for the whole application in terms of maintainability and scalability. I have done some applications that used some sort of XML messaging method, the last one I did was a webshop that used message queuing with XML messages. In that project isolation was mandatory, because the format of the data for the different subsystems was radically different. Building large n-tier applications is fun to do, but you got to keep a lot of things in mind when designing the solution WM. Yaaarrrr What about weapons of mass-construction? Sign In·View Thread·PermaLink But it's Saturday !!!! Brad Bruce 5:37 9 Jul '05   These are very clear articles. (For those who understand n-tier architectures ) I've been able to pull pieces from the first one and use them when explaining things to other developers and managers. Do you have a more introductory article planned? Even if it's a repeat of some of what is already in your articles, it could be useful when explaining things to managers & customers Sign In·View Thread·PermaLink 5.00/5 Re: But it's Saturday !!!! Chad Z. Hower aka Kudzu 10:47 9 Jul '05   I wrote the article earlier this week and just did final edits today. In fact, its based on an internal paper I did a year ago and on techniques I've been using for many years. Im glad its been useful to you, there are many more coming although Im sidetracking a bit to work on some other topics as well. Do you think there is anything I could cover in an intro that hasnt been covered many times over by others already? Chad Z. Hower, a.k.a. Kudzu "Programming is an art form that fights back" My Technical Stuff: http://www.hower.org/Kudzu/ My Blogs: http://www.hower.org/kudzu/blogs/ Sign In·View Thread·PermaLink Re: But it's Saturday !!!! Brad Bruce 7:07 10 Jul '05   I like your style of writing (and you're good with the graphics) Even if something has already been written, an article written in the same style as the detailed ones you've already written would provide a good connection between over-view and details. My original comment about Saturday, was that the article required concentration that isn't typical for a Saturday for me.... Sign In·View Thread·PermaLink 5.00/5 Re: But it's Saturday !!!! Chad Z. Hower aka Kudzu 12:38 10 Jul '05   Brad Bruce wrote: I like your style of writing (and you're good with the graphics) Thanks - it takes me a long time to get the articles to the level that Im happy with. It might not appear so, but some articles not including code are several days work. Brad Bruce wrote: Even if something has already been written, an article written in the same style as the detailed ones you've already written would provide a good connection between over-view and details. I'll put it on my future ideas list. Im working on quite a list of backlogged ideas, I'd like to clear the more unique ones out of the way first. Brad Bruce wrote: My original comment about Saturday, was that the article required concentration that isn't typical for a Saturday for me.... Aah. Saturday is just another day for me. Chad Z. Hower, a.k.a. Kudzu "Programming is an art form that fights back" My Technical Stuff: http://www.hower.org/Kudzu/ My Blogs: http://www.hower.org/kudzu/blogs/ Sign In·View Thread·PermaLink

Last Visit: 20:37 18 Mar '10     Last Update: 20:37 18 Mar '10 1