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

Good2Know: Your Resume Is Your #1 Marketing Tool

One’s career is also subject to the realities of life, that is, that there might come a time when you have to unexpectedly give your resume out to someone.  This could be because you are contacted by a recruiter with a really interesting position, or because your boss comes to you and suggests to you to start looking for a job.  That is why it is always good to have one’s resume ready to be sent at anyone’s request.  Working on your resume, however, can be a daunting task.  The web is plagued with so many formats and suggestions that one might suffer information overload when trying to convey one’s career on paper.

Marc Cenedella, founder of the site has written a blog that displays a resume belonging to none other than Leonardo da Vinci.  The resume, written in 1482 for the Duke of Milan, showcases the vast skills possessed by the genius inventor.  In this blog post Cenedella shows how even back then marketing oneself effectively can make the difference between just landing a job or taking the next career step.

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?

Good2Know: Fixing the orphan account issue on SQL Server

If you have done any type of programming involving SQL Server across different environments (Development, Test and Production) I’m sure you’ve ran across the annoying issue of orphan records.  Basically, when you are dealing with a user name in your development environment (your dev PC) a given user account is identified with an ID in your server (your development PC).  When you backup the database and restore it to another server (i.e. your test server) the user account might not exist in the  destination server (or might be under a different ID).  So when you are done deploying your application and you give it a first run you’ll encounter a user not found type message.  This gets even more annoying when you try to add the user and it tells you that your database already has a user with that name.  What happens is that the account does exist in the database but not in the server, creating an orphan account.

Luckily, Microsoft anticipated this issue and included a stored procedure to address it: sp_change_users_login (they still need to work on the name, though).

(the text below was copied from MSDN site at

A. Show a report of the current user to login mappings

This example produces a report of the users in the current database and their security identifiers.

EXEC sp_change_users_login 'Report'

B. Change the login for a user

This example changes the link between user Mary in the pubs database and the existing login, to the new login NewMary (added with sp_addlogin).

--Add the new login.
USE master
EXEC sp_addlogin 'NewMary'

--Change the user account to link with the 'NewMary' login.
USE pubs
EXEC sp_change_users_login 'Update_One', 'Mary', 'NewMary'

C. Automatically map a user to a login, creating a new login if necessary

This example shows how to use the Auto_Fix option to map an existing user to a login with the same name, or create the SQL Server login Mary with the passwordB3r12-36 if the login Mary does not exist.

USE pubs
EXEC sp_change_users_login 'Auto_Fix', 'Mary', NULL, 'B3r12-36'

First, run the sp_change_users_login 'Report' to see what 
accounts are being affected.  The results should look like something like this:

UserName UserSID ------------------------- ----------------------------------- AdminUser 0xC613C3AC32FBD745B364A7A36DA502FF DataAccessLayer 0x372E544EB918D54E834ADDFDD1506E4B
Then you can go one by one and fix them by running the
stored procedure for each account.
exec sp_change_users_login 'Auto_Fix','DataAccessLayer',null,'DALPassword'
That's it! As you can see, the fix is rather simple if
you figure out what the issue is and know how to Google it.