locked
Modelling Application Layers RRS feed

  • Question

  • User-2053374990 posted

    Hello everyone!

    I'm trying to create my first Asp.Net application from scratch. Tried to create this post in some of the other forums but I couldn't find a better place.

    So, as the title says, I'm having trouble trying to model my application. I'm like an OOP newbie. I'll show my classes first and then I'll write my questions.

    Model Layer

    public class User
    {
      private int id;
      public int Id { get { return id; } set { id = value; } }

      private string login;
      public string Login { get { return login; } set { login = value; } }

      private string password;
      public string Password { get { return password; } set { password = value; } }

    }

    Data Access Layer

    public class BasicDAL
    {
      private SqlConnection connection;

      //>>Returns a new connection to the database
      public SqlConnection GetConnection()
      {
        //>>If connection is active close it before starting a new one
        if (connection != null)
          if (connecion.State != ConnectionState.Closed)
            connection.Close();

        connection = new SqlConnection("MyConnectionStringHere");

        return connection;
      }
    }

    public class UserDAL : BasicDAL
    {
      //>>Insert a new user
      public void Insert(User user); { /* Insert into DB */ }

      //>>Authenticate user login with its password
      public void Authenticate(User user); { /* Authentication code here */ }
    }

    Business Logic Layer

    public class UserBLL
    {
    //>>Insert a new user
    public void Insert(User user); { /* What here? */ }

    //>>Authenticate user login with its password
    public void Authenticate(User user); { /* What here? */ }
    }


    Presentation Layer (InsertUser.Aspx)

    protected void ButtonInsertUser_Click(Object sender, EventArgs e)
    {
    User newUser = new User();
    newUser.Login = TextBoxLogin.Text;
    newUser.Password = TextBoxPassword.Text;

    UserBll bll = new UserBll();

    userBll.Insert(newUser);
    }

    So, model layer is pretty simple. Just a user representation. On the Data Access Layer I have a basic class with a GetConnection method. All DAL classes will extend this one.

    My first problem lies on Business Logic Layer. With the above scenario, I've placed the same methods that I placed at the DAL. BLL methods would call DAL. As simple as that but I believe It is not the best way to do it, is it? How can I improve those classes?

    Also, I have to "try..catch" blocks. That's because I can't find good places for it. I mean, if I place a try..catch on GetConnection method, for instance, how my ASPX page would get this error? How my ASPX page can tell the difference between "database offline" and "sql syntax error" when executing "userBll.Insert(newUser);".

    My problem is mainly placing the exception handlers. I understand I would probably have to change return type of some methods. I didn't change because I believe that will have something with the exception handlers.

    Btw, please assume I can't use TableAdapters and stuff like that. I would like to create all layers by myself.

    So, could you help me figuring this out?

    Thanks!

    Tuesday, January 26, 2010 7:10 PM

Answers

  • User-952121411 posted

    I'm like an OOP newbie.
     

    Welcome! Laughing

    My first problem lies on Business Logic Layer. With the above scenario, I've placed the same methods that I placed at the DAL. BLL methods would call DAL. As simple as that but I believe It is not the best way to do it, is it? How can I improve those classes?

    Here's the thing.  You have a good start.  The important general rule to keep in mind with a traditional n-tier UI->BLL->DAL architecture is separation of concerns.  Based on your descriptions you are doing that appropriately.  The BLL should make all calls to the DAL which in turn makes the lowest level db calls to get the data.  Then once the data is returned, you may parse that data out into business objects to be used.  I have found that with OOP, each time I write a new app I do something better than the last time I wrote one.  This process is just good to know because your 1st few times around are not going to be a slam dunk.  You will see after the app has been in production for a while, and how things flow which architectural changes make sense and make your application more manageable.  You might want to graze over the following couple of links for some general information on this topic:

    3-tier Architecture with ASP.NET 2.0 (select language):

    http://msdn.microsoft.com/en-us/library/aa581769.aspx

    Designing a .NET Application:

    http://msdn.microsoft.com/en-us/library/ms973829.aspx

    Application Design Guidelines: From N-Tier to .NET:

    http://msdn.microsoft.com/en-us/library/ms978384.aspx

    ...as far as exception handling goes.  That is like throwing a dart blindfolded.  It is tough to get a bullseye.  I don't think I have seen or heard more different ways of doing and opinions about any topic in .NET more than exception handling.  There are ton of ways to do it.  The best advice I can give is to centralize your exception handling in some manner.  This could be by creating or using an existing exception framework that wraps exception detail in an object.  I don't however think Try-Catch statements need to be avoided.  You do hear often "don't catch an exception unless you can do something meaningful with it"; this I do agree.  In its simplest form, let's say all you want to do is log the exceptions.  Then your DAL and BLL probably don't need any Try-Cacth statements at all. .NET will bubble the exceptions back up automatically.  You don't need a Try-Catch to have exceptions caught and thrown.  Then make sure that your top most level calling method has the Try-Catch (because you do not want a hard error to the screen) and catch, handle, and log the exception.  Exception handling is another area you will probably continually refine as you write more applications. 

    Well hope this bit of information helped! Smile

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, January 27, 2010 11:32 PM

All replies

  • User1611391320 posted

    Dear As far as

    BLL is concer

    ned it just calls method from DAL like

    In BLL:-

    DAL.Insert();

    For exception handling i think. best way would be to

    use them on Application_Error for whole site.

    For specific pages u can do on Page_Error also


    Wednesday, January 27, 2010 3:28 AM
  • User-481631678 posted

    YOur architecture seems fine to me. As far as exception handling is concern, do not add tons of Try/Catch in your code, this will decrease your system's performance and it will be difficult to develop. Use global exception handling techniques Application_Error for handling errors. For details see these articles:-

    http://www.codeproject.com/KB/aspnet/ASPNETExceptionHandling.aspx

    http://www.codeproject.com/KB/aspnet/ErrorHandlingASPNET.aspx


    Wednesday, January 27, 2010 3:51 AM
  • User-952121411 posted

    I'm like an OOP newbie.
     

    Welcome! Laughing

    My first problem lies on Business Logic Layer. With the above scenario, I've placed the same methods that I placed at the DAL. BLL methods would call DAL. As simple as that but I believe It is not the best way to do it, is it? How can I improve those classes?

    Here's the thing.  You have a good start.  The important general rule to keep in mind with a traditional n-tier UI->BLL->DAL architecture is separation of concerns.  Based on your descriptions you are doing that appropriately.  The BLL should make all calls to the DAL which in turn makes the lowest level db calls to get the data.  Then once the data is returned, you may parse that data out into business objects to be used.  I have found that with OOP, each time I write a new app I do something better than the last time I wrote one.  This process is just good to know because your 1st few times around are not going to be a slam dunk.  You will see after the app has been in production for a while, and how things flow which architectural changes make sense and make your application more manageable.  You might want to graze over the following couple of links for some general information on this topic:

    3-tier Architecture with ASP.NET 2.0 (select language):

    http://msdn.microsoft.com/en-us/library/aa581769.aspx

    Designing a .NET Application:

    http://msdn.microsoft.com/en-us/library/ms973829.aspx

    Application Design Guidelines: From N-Tier to .NET:

    http://msdn.microsoft.com/en-us/library/ms978384.aspx

    ...as far as exception handling goes.  That is like throwing a dart blindfolded.  It is tough to get a bullseye.  I don't think I have seen or heard more different ways of doing and opinions about any topic in .NET more than exception handling.  There are ton of ways to do it.  The best advice I can give is to centralize your exception handling in some manner.  This could be by creating or using an existing exception framework that wraps exception detail in an object.  I don't however think Try-Catch statements need to be avoided.  You do hear often "don't catch an exception unless you can do something meaningful with it"; this I do agree.  In its simplest form, let's say all you want to do is log the exceptions.  Then your DAL and BLL probably don't need any Try-Cacth statements at all. .NET will bubble the exceptions back up automatically.  You don't need a Try-Catch to have exceptions caught and thrown.  Then make sure that your top most level calling method has the Try-Catch (because you do not want a hard error to the screen) and catch, handle, and log the exception.  Exception handling is another area you will probably continually refine as you write more applications. 

    Well hope this bit of information helped! Smile

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, January 27, 2010 11:32 PM