CODEWITHSUNDEEP
c#.netdesign-patterns
capdragon
capdragon

Reputation: 14899

Always traverse the Business Layer to get to the Data Layer?

I have set up my VS Solution with the common layers in separate projects: Presentation, Business, Entities, and Data Access Layers. I have this static class AppSettings in the DAL which i want to call its Load() method at Application_Start in the Globla.asax.cs. It basically loads up my application settings from the web.config.

My question is: Should i be making a business logic class to access it from my Presentation Layer or can i access my AppSettings directly from my Presentation Layer to the DataAccess Layer (ignoring the Business Layer).

If so, does the same go for everything? Must i always go through the business layer to get to the Data Layer? 

public static class AppSettings
{
    public static int ApplicationID { get; set; }
    public static string ServiceEndpoint { get; set; }
    public static string ServiceCode { get; set; }
    public static string ConnectionString { get; set; }

    public static void Load()
    {
        //Connection String
        AppSettings.ConnectionString = System.Configuration.ConfigurationManager.ConnectionStrings["USpace"].ConnectionString;

        //Applicatin Settings
        AppSettings.ApplicationID = Convert.ToInt32(System.Configuration.ConfigurationManager.AppSettings["AppID"]);
        AppSettings.ServiceEndpoint = (string)System.Configuration.ConfigurationManager.AppSettings["ServiceEndpoint"];
        AppSettings.ServiceCode = (string)System.Configuration.ConfigurationManager.AppSettings["ServiceCode"];
    }
}

If i must go through the business logic Layer the BLL's class will look like this?:

public static class BLLAppSettings
{
    public static int ApplicationID
    {
        get
        {
            AppSettings.ApplicationID
        }
    }
 ...

Upvotes: 2

Views: 1595

Answers (5)

dblood
dblood

Reputation: 1778

You should start out by keeping it simple but within reason. General principles of software engineering should be your guide when designing your application. In this case, my immediate thought is that by having one global AppSettings class then you will be coupling your business and data access layer to that class. That may seem reasonable now but what about when you have 50 different settings and only 20 of them apply to the data access layer? What if, down the road, your business layer has to load the settings from a different source than the DAL? On top of that, in your current design your coupling both layers to global singleton. That is typically not a good idea.

Even in smaller apps I would advocate for having different settings objects defined for each layer. In my design, it would be similar to your BLLAppSettings. It would encapsulate the source of the settings, in this case your global AppSettings class. However, where my design would differ is that BLLAppSettings would be a concrete instance of an Interface defined in the BLL layer that must be given to the BLL layer via Constructor, Factory, or Dependency Injection. A similar class, DALAppSettings would be necessary in my recommended design.

In this way, your BLL and DAL are not coupled to the global AppSettings defined in the Presentation Layer. The implementation details of BLLAppSettings and DALAppSettings can vary independently when necessary, but for the time being can remain internally tied to your global AppSettings class.

Upvotes: 1

Jason
Jason

Reputation: 15931

If the data is in the application's config file (web.config) you don't need to "go through" anything besides System.ConfigurationManager.AppSettings

Upvotes: 1

remi bourgarel
remi bourgarel

Reputation: 9389

Ayende recently posted a few articles against this practice (I understood it like that) :

http://ayende.com/blog/153061/northwind-starter-kit-review-it-is-all-about-the-services

And I agree with him : you have to ask your self "what is the purpose of this layer" and if you can't answer then you can't remove this layer and keep your software simple.

So if you have no business operation when you get your data then deal directly with your data layer !

Upvotes: 1

ERukes
ERukes

Reputation: 51

I would recommend always going through the business logic layer to access the data layer, so that all of the safeguards built into the business logic layer are in play. Would you want the data layer to be used without the business layer?

Upvotes: 3

ShaneBlake
ShaneBlake

Reputation: 11096

If your focus is Design Patterns, then by all means, have fun pounding those square pegs in the little round holes.

If your focus is on Application Design, then you focus on the Design Patterns that make sense for your Application, and even for individual parts of your Application.

Knowing the patterns is knowledge. Knowing when, and when not, to use them is wisdom...

It's one man's oppinion, but I hope it helps...

Upvotes: 1

Related Questions