This post originated from an RSS feed registered with .NET Buzz by Sean McCormack. Original Post: A Lesson on N-Tier Architectures Feed Title: Vini Vidi Vici - Sean McCormack's Blog Feed URL: http://smccormack.blogs.com/adapdev/SyndicationService.asmx/GetRss Feed Description: Sean McCormack's Blog, focusing on various aspects of .NET development, open source projects, recommended books and tools Latest .NET Buzz Posts Latest .NET Buzz Posts by Sean McCormack Latest Posts From Vini Vidi Vici - Sean McCormack's Blog

As I mentioned previously, I've been doing a lot of technical screenings lately.  Another comical item that keeps coming up is the usage of the term “N-Tier”, a greatly abused and misunderstood term.  I think developers use this, like many other terms, without really understanding what it means.

In a couple of interviews, I had individuals tell me that their teams used N-Tier architectures.  I'd ask them to explain N-Tier in layman's terms - and everyone got it right.  It's the logical and/or physical separation of responsibility, often times comprising a presentation layer, business logic layer, service layer, data access layer, etc.

The problem arises when I ask them to explain to me how an application utilizes N-Tier technology.  I have them walk me through a web form that needs to display a customer record stored in a database.

Almost 90% of the developers respond with the following:

I would have an ASP.NET page call a method that does a select statement from the Database, return a DataSet, and bind the DataSet to a DataGrid in the web page.

Sounds straight-forward.  But, where are the layers?

The method is the Business Logic layer.  The database is the Database Access Layer.  The web page is the Presentation Layer.

Wrong.  The first issue is that your Data Access logic is embedded in your page - which is your Presentation Layer.  What if you need that same select query to be performed in a different page?  You'd have to copy and paste, which means you haven't centralized your Data Access layer, so it's essentially non-existent.  Also, a Data Access Layer means just that - accessing the data.  A database is a data store, so you can't say that your database is your Data Access Layer.  Somehow you have to get data in and out, which is what the DAL does.

Secondly, the Business Logic Layer is none existent in the above example.   A Business Logic Layer is composed of Business Objects.  A Business Object encapsulates business functionality.  Returning a DataSet is not business logic - it's data access.  An example of a Business Object is an Order object that calculates tax using defined business rules.

In the above example, all they have is a Presentation Layer that's doing everything.  This is NOT N-Tier architecture.

An example of an N-Tier architecture would be an a web page that has a View pattern definition for a given Business Object (in this case a Customer object).  The application would call a Data Access Layer (such as nHibernate, etc.) and return a populated Business Object.  The Presentation Layer would then apply one of many Views to that Business Object.

This does several things.  One, your data access logic in centralized.  You could switch the backend database from Oracle to Sql Server and it wouldn't impact your Business Logic or Presentation Layers (not the case in the example - it's collapsed into one layer and compiled into one dll).  Secondly, your Business Logic is now isolated in a layer and you have a logical representation of data through an object.  A Customer object may encapsulate many business rules, and it may also contain a hierarchy of related information, such as Orders, Addresses, etc.  If you return a DataSet, all of this is stored in a relational manner and not an object-oriented manner.  A Business Object allows you to provide a business-centric OO view of information.  Thirdly, you can quickly switch the UI to provide different views of the same data, since you now have an object to base it off of.  Using the View pattern, you could have 3 different UI representations of the data and switch the view according to the context.  Most imporantly, all of this code is separated into different dlls using interfaces (ideally) as the contracts.  This allows me to change the innards of my DAL and redeploying without making any changes to my other layers or affecting them.

Adding a Service Layer puts in another separation.  This is when you're dealing with distributed architectures and calling Web Services, etc.  This gets a lot more complicated, so I'll avoid it in this example (I don't feel like typing a lot ;-)).

So, the lesson is N-Tier is NOT calling a stored procedure or doing a select statement from within an ASP.NET page.  Unfortunately, this appears to be a very common response.

Don't get me wrong - there are times where having a simple web page call a database directly and bind to a grid makes sense.  But, you need to understand that it's a flat architecture.  Doesn't mean it's wrong (depending on the circumstance ;-)) but it's not N-Tier.

Updated 8/29 - Srdjan brought up a good point.  It's important to note that N-Tier can mean either a logical or physical architecture.  The example above deals with a logical architecture.  If a candidate were to give me a physical architecture answer (most give a logical architecture answer), then I'd have them describe the physical architecture instead.