locked
My first 3-tier web application RRS feed

  • Question

  • Dear All,

    I decided to design my next web application as a proper 3-tier instead of a simple one project as i did usual. I created a web application as the UI layer, and added 2 more class library projects one for BL and one for DAL. Then i got confused. Usually i store all the application settings in web.config, but now as the projects are separated im not sure its the appropriate way. All 3 tier needs different settings, forexample DAL needs a connection string to access db, BL log class needs a log file path, etc...

    Shall i keep using the web.config of the UI layer to store all the app. settings, or should it be separated from each other, or it doesnt matter at all?

    Thanks in advance.

     

    Wednesday, July 13, 2011 1:08 PM

Answers

  • You can keep it in web.config. It is accessible by all layers anyway if these are in memory class library dlls. So, as long as you keep the name value pairs unique, it does not matter. Here are some considerations though: None of these are rules, just alternate ideas:

    1. Try and define custom sections for each layer if each layer depends heavily on the config parameters

    2. Usually, putting a value in config file adds to the configuration capability of the application. But in a multi layer project, as you guessed, it can lead to confusion [i.e. is there a clash?]. A common approach is to create a simple class that is responsible for reading configuration values only and make this class a part of a utility project which can be used by all layers. i am not suggesting you create a project just for this. But if you have other common requirements [i.e. logging / common data transformation routines, encryptions, common algotirhms] you can consider creating a utility library.

    3. An alternate to item 2 is, try and keep all configuration values in one place [preferrably in the web layer] and pass these to the lower layers as function arguments. But this changes your api signatures.

    • Marked as answer by ElBandito Friday, July 15, 2011 7:34 AM
    Wednesday, July 13, 2011 1:41 PM

All replies

  • You can keep it in web.config. It is accessible by all layers anyway if these are in memory class library dlls. So, as long as you keep the name value pairs unique, it does not matter. Here are some considerations though: None of these are rules, just alternate ideas:

    1. Try and define custom sections for each layer if each layer depends heavily on the config parameters

    2. Usually, putting a value in config file adds to the configuration capability of the application. But in a multi layer project, as you guessed, it can lead to confusion [i.e. is there a clash?]. A common approach is to create a simple class that is responsible for reading configuration values only and make this class a part of a utility project which can be used by all layers. i am not suggesting you create a project just for this. But if you have other common requirements [i.e. logging / common data transformation routines, encryptions, common algotirhms] you can consider creating a utility library.

    3. An alternate to item 2 is, try and keep all configuration values in one place [preferrably in the web layer] and pass these to the lower layers as function arguments. But this changes your api signatures.

    • Marked as answer by ElBandito Friday, July 15, 2011 7:34 AM
    Wednesday, July 13, 2011 1:41 PM
  • Hm, i was also thinking about to create a separated utility library, but was not sure to make it as a different project.
    As you are absolutely right, theres some common routines, like logging, authentication, which should be separated from the BL itself.

    My concept was the following:

    Theres 3 different projects:
    - app.GUI
    - app.BL
    - app.DAL

    and within app.BL i created different folders like Authentication, Logging, BL in order to separate the classes of common functions and BL.
    A configuration class like this could be created there:

    public class Config
    {
      public static string ADAdminGroup
      {
        get { return ConfigurationManager.AppSettings.Get("AD_Admin_group"); }
      }
    
      public static string ConnectionString
      {
        get { return ConfigurationManager.ConnectionStrings["myConn"].ConnectionString; }
      }
    }

    Do you think this would be appropriate? The class is located in BL project and reading web.config from GUI?
    Or shall i create a completelly separated project for the utilities like this:

    - app.GUI
    - app.BL
    - app.Utils
    - app.DAL

    Thanks for all!
    Thursday, July 14, 2011 7:29 AM
  • Hi,

    I will not recommend having configuration settings in Utility... Utility is a class library one can use across multiple applications irrespective of type...This should contain common problems and repeatable code block usages.

    In common practice, will add configuration settings in web.config itself.


    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".
    Thursday, July 14, 2011 11:54 AM
  • Kris444, to clarify your concerns, i am not suggesting values be taken out of web.config. But all i am saying is where there are multiple layers depending on configuration, the "reading" of the configuration should be abstracted. You can create a ConfigurationReader class that can have methods like

    GetThresholdValue, GetDBInformation etc. these are example configuration items you will read.

    What this does is, going into the future gives you a much better idea/control on how configuration items are used because you simply need to undertstand and document 1 class that is abstracting the reading of the configuration values.

    That said, these are not rules written in stone :) i have implemented this myself in several projects and have realized that it is easier to maintain configuration values if we can clearly identify how these are used, and one good way to do that is to abstract the reading of the values.

    Thursday, July 14, 2011 3:19 PM
  • Hi

    Sambeet, This part of the text

     A common approach is to create a simple class that is responsible for reading configuration values only and make this class a part of a utility project which can be used by all layers.

    made me to think in that way....never mnd

    Yes i do suggest, as you told creating abstract layer for accessing configuration from web.config is good idea...

     

    CrazyBaboon, 

    I suggest have separate project like app.Core, Which can contain all framework related/common classes across application.

    so you will have

     

    app.GUI

    app.Core

    app.BAL

    app.DAL

    and also you can have app.Util which can be refered by all other projects...

     

    Hope this helps you....




    If this post answers your question, please click "Mark As Answer". If this post is helpful please click "Mark as Helpful".
    Friday, July 15, 2011 5:02 AM
  • Hi there!

    Thanks, i will create a Util layer refered by the other projects (GUI, BL, DAL), as Sambeet suggested. My only concern how can the web.config be reached by the Util? Can the usual ConfigurationSettings.AppSettings.Get() be used? I will try it, and be back if still have questions. :)

    Friday, July 15, 2011 7:34 AM
  • I tried it. The System.Configuration must be added manually as a reference to the Util layer/project in order to use ConfigurationSettings.AppSettings.Get(). Thats do the trick. Thanks to both of you again!
    Friday, July 15, 2011 12:13 PM