Skills2Know: N-Tier Application Development

Books have been written on this subject and this post is by no means attempting to come close to covering everything there is to know about this subject.

At the very top of your application you’ll have some sort of presentation layer. It can take several forms such as Web, Windows or Apple, Mobile you name it. They all do pretty much the same thing in that they display data to the user. What comes below that varies on the design and there isn’t no one-size-fits-all formula you can use to design an application beyond this point.

Some systems will have three layers: Presentation, Business Logic and Database

The key of a design is to separate the awareness among layers.  In this case, the presentation layer will not be aware of the database, but rather access the database by way of objects within the Business Logic Layer.  If the UI (User Interface, another name for Presentation Layer) has a line of code that resembles a SQL statement, database credentials or a table name then chances are you are breaking a design rule.  The UI should access the data by calling methods contained in the classes of the BLL (Business Logic Layer) that in turn do the actual call to the database.  This way we abstract the call to the database.

So a call to the BLL from the UI would look like this:

While the call from the BLL to actually retrieve the data would be made from the Retrieve method of the Employee class

What you get here is a very flexible design that if something changes in the database because if anything changes in the database, like a change in table structure, no changes are required in the UI.  The key of N-Tier Application design, however, is to minimize the changes in one layer that force a change in another layer.  So in this case, that a change in the database table structure caused a change in the BLL is not necessarily something we want to happen.  We need a way to abstract changes in the database layer from the BLL so that even if we change table structure in it the BLL is not affected.  There is also the fact that one could argue your BLL is too close to the database.  Remember that the BLL should handle business logic, that is, logic pertaining to the application.  So far, our BLL is doing both, business logic and retrieving data.  We can eliminate these two issues, the database layer abstraction and the separation of the data extraction in the BLL by making two changes:

  1. We first address the issue with the BLL by implementing a Data Access Layer (DAL).  The sole purpose of this layer is, you guessed it, access data from the database for the BLL.  The BLL is no longer aware of the database, it rather calls the DAL and it asks for the data.  The DAL then gets the data and returns it to the BLL.
  2. We create stored procedures (SPs) that will act as a layer between the actual tables and the DAL.  This will not only abstract the table structure to the DAL (making the changes to tables only affect SPs) but it improves performance as SPs are pre-compiled by the database environment and will perform faster than just a straight SQL query.

So our BLL code would change to look something like this:

And the DAL code might look something like this:

Notice how if something changes in database, the BLL does not need to change.  The DAL is also insulated from such changes because the name of the SP and the parameters we pass wouldn’t change either.  So a change in one layer (the database) would not trigger a change in the other.  This approach is used extensively in enterprise level applications for obvious reasons.  Imagine all your layers were in different servers, making a change in one layer that meant change others would not only mean a change in the code but also a redeployment of several layers which more testing required which could quickly turn into a maintenance nightmare.  Having said that, this design can be used for smaller applications if at all, to make the code more readable.  In the real world, a small application with a few users can turn into an enterprise application overnight, so developing applications in layers, regardless of their size, will always mean less work in the long run.  Noticed that we end up with a very light UI because all the heavy lifting is done by the BLL, the DAL and the database Stored Procedures.  Switching from WinForms to a web app or to any other platform for that matter would be very simple because of how light the presentation is.

One last thing:  Always think of layers in terms of awareness.  Does my UI know about where the BLL goes to get the data it needs.  Does my BLL know anything about the data store.  Does the DAL know there is a table called Employee.  If a layer knows more than it needs to know then you are creating dependencies that will get you in the long run.

This was meant to be a very high, simple overview of what an N-Tier application might look like.  I didn’t want to get too much into the details of how to develop a BLL or DAL because depending on your preferences and needs there are all sorts of ways of implementing such layers.

For a more in detail read on this subject go to:

Part 1 : What is N-Tier Architecture?

Part 2 – How to implement the Business Layer

Part 3 – How to implement the Data Layer

Code Sample click here

Skills2Know: Building N-Tier Apps with EF4

Daniel Simmons, a member of the Entity Framework Development Team,  has written a very useful set of articles on N-Tier Application Design with the Entity Framework (EF).  The articles cover general concepts in N-Tier Application Design and showcases the EF’s way to address them.

Anti-Patterns To Avoid In N-Tier Applications

N-Tier Application Patterns

Building N-Tier Apps with EF4

One thing to keep id mind with new technologies like the EF is that they should not become your end-all, be-all tool.  As a developer and application designer one should look carefully into what the best tool for a job is.  If a framework such as the EF is a good fit then use it, but one should always avoid falling into the trap of looking at everything as a nail because what I am holding in my hand is a hammer.  Put down the hammer and look at what’s in front: Is it a nail or a screw?

Good2Read: ASP.NET 2.0 Website Programming: Problem – Design – Solution

If you have been programming for a while you have come to understand that the only way to keep up with the ever growing amount of technology Redmond throws at us is to read…constantly…without stopping.  The fact that everybody and their mother seems to be writing nowadays doesn’t help the situation either.  Over the years I’ve come to identify authors and publishers that seem to produce quality books on a variety of subjects.  Authors like like Carli Watson, Rockford Lhotka, Steve McConnell (to name a few) put out quality on everything they write.

A new face in the good authors line up is Marco Bellinaso.  Marco wrote ASP.NET 2.0 Web Site Programming which turned out to be a great book I always recommend to someone that knows some ASP.NET and wants to take their development of enterprise level applications to the next level.  Marco has done an excellent job at outlining what I think should be the path every developer takes in identifying the problem at hand, designing the application and providing a solution to the client.  Reading Marco’s book is a delight for the one seeking how serious development is done.  It is the kind of book that you wear out from frequent reading because it could easily become part of one’s library of reference books.

If you are looking for a sound approach to the world of web development look no further, you have arrived.  Reading this book you’ll learn concepts like how UML design fits in the overall planning stage, how designing a  Data Access Layer (DAL) and a Business Logic Layer (BLL) prior to any UI implementation (what a concept right?) is the key to an application that can withstand the test of time and much more.  Marco’s conversational writing approach makes the learning of these important concepts simple to understand and implement.

Good2Know: Contrasting the ADO.NET DataReader and DataSet

Today I stumbled upon John Papa’s article on the June 2004 issue of the MSDN Magazine. He discusses a question that every developer asks when dealing with ADO.NET. What do I use, the dataset or datareader object? This question should never be asnwered based on familiarity, rather based on design. Why design? Because as John discusses there are scenarios where one is better than the other.

Read this article that so clearly provides the information necessary to make those tough design decisions (notice the enphasis on the word desgin) [:)].