locked
I have great doubt about BLL layer RRS feed

  • Question

  • User-1011572351 posted
    I have great doubt about BLL layer

    Repository Pattern replaces DAO, correct?

    So, I have

    Models - My Class
    BLL - for Business Class, where validations do business with the models - and here I use the repository to access data
    Repository - Class for data access (SAVE / UPDATE / DELETE AND GETS / getByAny)


    This assessment is correct? between Bll class and repository class ?

    If not, can someone show me a simple example code?

    Theory helps, but confuses, like the example code please
    Thursday, July 3, 2014 10:17 AM

Answers

  • User281315223 posted

    About the Repository Pattern

    The Repository Pattern is a design pattern that allows you to further abstract and separate some of the logic involved when accessing data (instead of directly accessing it and adding logic in each time). This can help eliminate duplicate code throughout your applications, it can assist with testability and much, much more. This Stack Overflow discussion provides an excellent step-by-step explanation of it which you might find helpful.

    Differences between Data-Access and Business Logic

    Your implementation of the Repository Pattern isn't really going to make any changes within your Business Logic layer necessarily (this isn't saying that it can't be used in this manner), however it's likely going to play a larger role in the data-access layer instead (specifically to access data). 

    You'll just be using the Repository to actually access your data, which you can see in a very basic Repository implementation below from this blog discussion on the Repository pattern :

    public class CustomerRepository : ICustomerRepository
    {
        private NorthwindEntities db = null;
     
        public CustomerRepository()
        {
            this.db = new NorthwindEntities();
        }
     
        public CustomerRepository(NorthwindEntities db)
        {
            this.db = db;
        }
     
        public IEnumerable<Customer> SelectAll()
        {
            return db.Customers.ToList();
        }
     
        public Customer SelectByID(string id)
        {
            return db.Customers.Find(id);
        }
     
        public void Insert(Customer obj)
        {
            db.Customers.Add(obj);
        }
     
        public void Update(Customer obj)
        {
            db.Entry(obj).State = EntityState.Modified;
        }
     
        public void Delete(string id)
        {
            Customer existing = db.Customers.Find(id);
            db.Customers.Remove(existing);
        }
     
        public void Save()
        {
            db.SaveChanges();
        }
    }

    Basically, all this will do is make it a bit easier to access your data (by abstracting it a bit). After grabbing your data, you'll then pass the raw data to a specific class that will handle both applying your business logic and validation (this is where your business logic layer and your data access layer meet) :

    // Grab a customer from your database (via the Repository)
    using(var db = new CustomerRepository())
    {
         // Get your customer object
         Customer c = db.SelectByID(42);
    }

    If you are using something like MVC, you could apply validation attributes on your actual Customer class itself to handle applying some business rules and validation as seen below :

    public class Customer
    {
         [Required]
         public string Name { get; set; }
    
         // Other properties here
    }

    This would allow you to either apply your rules on the same class that you are pulling from your Repository or you could build a separate class that would essentially do the same thing. 

    I would recommend reading over the following discussions in hopes that they might provide a bit more clarity : 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 3, 2014 5:00 PM
  • User-821857111 posted

    Models - My Class

    Yes

    BLL - for Business Class, where validations do business with the models

    Yes. 

    Repository - Class for data access (SAVE / UPDATE / DELETE AND GETS / getByAny)
    Yes.

    This assessment is correct? between Bll class and repository class ?

    Yes.

    Repository Pattern replaces DAO, correct?
    They are alternative approaches, yes.

    It seems you me that you understand this very well.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 3, 2014 5:35 PM

All replies

  • User281315223 posted

    About the Repository Pattern

    The Repository Pattern is a design pattern that allows you to further abstract and separate some of the logic involved when accessing data (instead of directly accessing it and adding logic in each time). This can help eliminate duplicate code throughout your applications, it can assist with testability and much, much more. This Stack Overflow discussion provides an excellent step-by-step explanation of it which you might find helpful.

    Differences between Data-Access and Business Logic

    Your implementation of the Repository Pattern isn't really going to make any changes within your Business Logic layer necessarily (this isn't saying that it can't be used in this manner), however it's likely going to play a larger role in the data-access layer instead (specifically to access data). 

    You'll just be using the Repository to actually access your data, which you can see in a very basic Repository implementation below from this blog discussion on the Repository pattern :

    public class CustomerRepository : ICustomerRepository
    {
        private NorthwindEntities db = null;
     
        public CustomerRepository()
        {
            this.db = new NorthwindEntities();
        }
     
        public CustomerRepository(NorthwindEntities db)
        {
            this.db = db;
        }
     
        public IEnumerable<Customer> SelectAll()
        {
            return db.Customers.ToList();
        }
     
        public Customer SelectByID(string id)
        {
            return db.Customers.Find(id);
        }
     
        public void Insert(Customer obj)
        {
            db.Customers.Add(obj);
        }
     
        public void Update(Customer obj)
        {
            db.Entry(obj).State = EntityState.Modified;
        }
     
        public void Delete(string id)
        {
            Customer existing = db.Customers.Find(id);
            db.Customers.Remove(existing);
        }
     
        public void Save()
        {
            db.SaveChanges();
        }
    }

    Basically, all this will do is make it a bit easier to access your data (by abstracting it a bit). After grabbing your data, you'll then pass the raw data to a specific class that will handle both applying your business logic and validation (this is where your business logic layer and your data access layer meet) :

    // Grab a customer from your database (via the Repository)
    using(var db = new CustomerRepository())
    {
         // Get your customer object
         Customer c = db.SelectByID(42);
    }

    If you are using something like MVC, you could apply validation attributes on your actual Customer class itself to handle applying some business rules and validation as seen below :

    public class Customer
    {
         [Required]
         public string Name { get; set; }
    
         // Other properties here
    }

    This would allow you to either apply your rules on the same class that you are pulling from your Repository or you could build a separate class that would essentially do the same thing. 

    I would recommend reading over the following discussions in hopes that they might provide a bit more clarity : 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 3, 2014 5:00 PM
  • User-821857111 posted

    Models - My Class

    Yes

    BLL - for Business Class, where validations do business with the models

    Yes. 

    Repository - Class for data access (SAVE / UPDATE / DELETE AND GETS / getByAny)
    Yes.

    This assessment is correct? between Bll class and repository class ?

    Yes.

    Repository Pattern replaces DAO, correct?
    They are alternative approaches, yes.

    It seems you me that you understand this very well.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, July 3, 2014 5:35 PM