interaction between data data acess layer and business layer

Question

i'm beginner in repository and layerd application and i don't inderstand well which is the interaction and the relationship between the repositories and business layer classes

Here is an example for purchaese order in 3 layers and I want to review whether correct or not and your correction

for DataAcesslayer

repository OrderRepositolry

    Namespece Dal
    {
       Public class RepositoryOrder
       {
              POrderContext context = new POrderContext ();
 
              Public IEnumrebale <Order> GetAll ()
              {
                   Context.Orders;
              }
// Following code
       }
    }

for the item of order repositories code :

namespece Dal
{
      public class RepositoryOrderItem
      {
             POrderContext context = new POrderContext();

             public IEnumrebale<OrderItem> GetAllItemById(Order o)
             {
                  context.OrderItems.where(i => i.OrderId == o.Id);
             }

            public OrderItem GetItemById(int id)
            {
                 context.OrderItems.Find(id);
            }
//Following code
      }
}

for businessLayer here is classOrderBLL code:

namespace BLL
{
      public class OrderBLL
      {
            RepositoryOrder repoOrder = new RepositoryOrder();
            RepositoryOrderItem repoItem = new  RepositoryOrderItem();

            public IList<Order> GetAll()
           {
               return repoOrder.GetAll();
           }

            public decimal GetPrixTotal(Order order)
           {
                var query = from item in repoItem.GetAllItemById(order)
                                 select sum(item=>item.Prix * item.Quantite);
                return query;
            }
      }  
}

1. does the total price calculation is done at the level of repository or at the level of BLL (we can make this request linq with context in the repository)?

2. CRUD method is done at repository and they are called at BLL from repository is it right?

3. does the where method in linq corresponds to logical business or
   repository (data access layer) since it determines certain rules in the business?

Answer 1

I'm sure this question will be voted down as "primarily opinion based" but before that happens I'll jump in to give my "primarily opinion based" answer :-)

There are two ways to partition a database application and they depend on how complex and large it will be. Entity Framework examples tend to give a very simplistic model, where the EF Data classes are exposed to the Business layer which then exposes them to the View Model or other layers. This may be correct for simplistic applications but for more complex ones, and ones where the data storage method is not RDBMS (i.e. No-SQL) or where you want to create separation between business and repository data structures it is too simple.

The repository layer should have a set of classes which describe how the data is accessed from the repository. If you have an RDBMS these might be EF POCO classes, but if you have a web-service endpoint as your repository this may be SOAP documents, or REST structures, or other Data Transfer Object. For an RDMBS like SQL Server that uses exclusively stored procedures for accessing its data, the Repository layer might simply be a set of classes which mirror the naming and parameters, and data sets returned by the stored procedures. Note that the data stuctures returned by anything other than an RDBMS might not be coherent - i.e. a "Customer" concept returned by one method call in the repository might be a different data structure to a "Customer" returned by a different call. In this case the repository classes would not suit EF.

Moving to the business object layer - this is where you create a model of the business domain, using data classes, validation classes and process class models. For instance a Process class for recording a sales order might combine a Business Customer, Business Sales Order, Business Product Catalog data concepts and tie in a number of Validation classes to form a single atomic business process. These classes might (if you are doing a very lightweight application) be similar to data at the Repository layer but they should be defined seperately. Its in this layer you hold calculated concepts such as "Sales Order Total" or "VAT Calculation" or "Shipping Cost". They might, or might not, get stored into your Repository but the definition of what they mean are modelled in the business layer.

The business layer provides the classes whose data is copied across into a View Model. These classes again can be very similar (and in the simplest of cases, identical to) the repository classes, but in their job is to model the user interface and user interaction. They might contain only some of the data from the business data classes, depending on the requirements of the UI. These classes should carry out user interface based validation, which they might delegate to the business tier, or might add additional validation to. The job of these classes is to manage the state-machine that is the user interface.

My summary is that in a large scale system you have three sets of classes; data repository interaction, business model interaction, and user interface interaction. Only in the simplest of systems are they modelled as a single set of physical POCO classes.