1 Requirements

  • Windows 7 Enterprise Edition (32-Bit OS)
  • .Net Framework 3.5 SP1
  • C# Compiler Version 3.5.30729.4918
  • Visual Studio 2008 Version 9.0.30729.1


2 Problem

Recently, I have been seeing people developing N-layer applications coding all classes from all layers with the public access modifier. The motivation for that is because functionalities that reside on an assembly needs be accessed from the previous assembly in the call stack, for example, a class on the business logic layer needs to access another in the data access layer. Depending on the size of your team, the application complexity, project milestones and deadlines, etc., this design decision can lead to undesired results, such as:

  • Inexperienced developers can accidentally make a mess with the calls, for example, coding the presentation layer to access directly the data access layer.
  • Developers pressured by a tight milestone/deadline can be tempted to do exact the same of previous item.
  • Suddenly, you realize that the robust exception handling mechanism implemented on the façades in the business logic layer is not working for several features. Moreover, the integration with third-party applications won’t be that easy because several features do not have a business logic entry.

Before getting the hands dirty, I do think is important to state several concepts regarding layers.
Dividing the application in layers allows you to create logical divisions to group code that have similar purpose. On one hand, this can help developers to understand how the application is organized, where they should put their code, etc. However, on the other hand, keep in mind that a logical architecture is not required to make your application work. Also, try not to confuse the term layer with tier, which is more related to physical division (process and/or machine). Below, there is an illustration of a simple N-layer application:




3 Workaround

There are several workarounds that can be applied to solve the encapsulation problems presented on the previous section.

One possibility it to create the layers on only one logical unit (assembly) coding all BLL, DAL and DTO classes and/or structs, which should be exposed with the internal access modifier, for example:



I have been hearing several people discussing about this approach not being efficient, because the project would always be checked out to another developer, becoming a contention point during coding phase. Presonaly, I think this can be true on several scenarios, such as:

  • Project has more than least 20 developers and coding phase is soaring with people are adding objects to the Visual Studio project like crazy.
  • Project has 5 developers and a couple of them constantly forget to check-in the project after adding an object, preventing others to do their jobs. This can be a consequence of: lack of a simple check-in/check-out process; or inexperience of a team member, who does not know the trouble his making to others or he is to focus to get the job done and just forget to check-in the project.

Tip: after adding an object to a project, for example, a class, make the check-in without starting coding, this way you avoid breaking the code. After that, check the file out and start getting your hands dirty.

Another approach would be having the layers separated in different assemblies, coding all classes with the internal access modifier and configuring which assemblies would be able to make calls to these internal functionalities.
To better exemplify this approach, the following steps will describe how it is possible to exposed functionalities from the Data Access Layer (DAL) only to the Business Logic Layer (BLL), supposing that DAL classes have the internal access modifier specified:



  • Sign both Application.BLL.dll and Application.DAL.dll with a strong name (through VS IDE or sn.exe);
  • Get the public key from the Application.BLL.dll assembly with sn –Tp Application.BLL.dll;
  • Configure Application.DAL.dll to expose internal classes to Application.BLL.dll. This can be achieved through adding the [assembly: System.Runtime.CompilerServices.InternalsVisibleTo(”Application.BLL, PublicKey=002400000480000094000000060200000024000052
    53413100040000010001003396ebc2b7199d23b73c40982b891fb3eb
    ecaa93deceaf189f12b38b252d7e144991ad1736ab900945e5b3d0e0
    15e833631cadb239c8325baa3f7662c7b1208456173cc8b233485bee
    32e4c8b5292b0d26703585737de948af9d95318751df369896a76cfb
    561ec1cad90a324a131bfeb7ecb54c9f35f262c2851234749ec8c9″)]     in the AssemblyInfo.cs in Application.DAL project. Caution: your public key will be different from the one in this example;
  • Compile your solution and go for it.