Interaktion zwischen Daten Daten acess Schicht und Business-Schicht

Question

i Anfänger sind in Repository und layerd Anwendung und ich weiß nicht inderstand gut, welche die Interaktion und die Beziehung zwischen den Repositories und Business-Schicht-Klassen

Hier ist ein Beispiel für purchaese Auftrag in 3 Schichten, und ich möchte, ob richtig oder nicht und Ihre Korrektur überprüfen

für DataAcesslayer

Repository OrderRepositolry

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

für das Element der Ordnung 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 
     } 
} 

für businessLayer hier ist 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. ist die Gesamtpreisberechnung auf der Ebene des Repository erfolgt oder die Ebene von BLL (wir können diese Anfrage linq mit dem Kontext im Repository machen)?

2. CRUD-Methode ist im Repository getan und sie werden bei BLL von Repository aufgerufen, ist es richtig?

3. tut das in dem Verfahren in Linq zu logischem Geschäft oder
   Repository (Datenzugriffsschicht) entspricht, da es in das Unternehmen bestimmte Regeln bestimmt?

Answer 1

Ich bin sicher, diese Frage wird als niedergestimmt werden „in erster Linie Meinung basiert“, aber bevor das passiert ich springen werde meine „in erster Linie Meinung basiert“ Antwort zu geben :-)

Es gibt zwei Möglichkeiten, eine Datenbankanwendung zu partitionieren, und sie hängen davon ab, wie komplex und groß es sein wird. Entitäts-Framework-Beispiele geben tendenziell ein sehr vereinfachtes Modell vor, bei dem die EF Data-Klassen der Business-Schicht ausgesetzt sind, die sie dann dem View-Modell oder anderen Layern aussetzt. Dies kann für einfache Anwendungen korrekt sein, aber für komplexere, und solche, bei denen die Datenspeicherungsmethode nicht RDBMS (d. H. No-SQL) ist oder wo Sie Trennung zwischen Geschäfts- und Repository-Datenstrukturen erstellen möchten, ist dies zu einfach.

Der Repository-Layer sollte eine Gruppe von Klassen enthalten, die beschreiben, wie auf die Daten vom Repository aus zugegriffen wird. Wenn Sie über ein RDBMS verfügen, handelt es sich möglicherweise um EF POCO-Klassen. Wenn Sie jedoch einen Web-Service-Endpunkt als Repository verwenden, können dies SOAP-Dokumente oder REST-Strukturen oder andere Datenübertragungsobjekte sein. Für einen RDMBS wie SQL Server, der ausschließlich gespeicherte Prozeduren für den Zugriff auf seine Daten verwendet, kann die Repository-Schicht einfach eine Gruppe von Klassen sein, die die Namen und Parameter sowie die von den gespeicherten Prozeduren zurückgegebenen Datensätze spiegeln. Beachten Sie, dass die Datenstrukturen, die von etwas anderem als einem RDBMS zurückgegeben werden, möglicherweise nicht kohärent sind - d. H. Ein "Kunden" -Konzept, das von einem Methodenaufruf im Repository zurückgegeben wird, könnte eine andere Datenstruktur als ein "Kunde" sein, der von einem anderen Aufruf zurückgegeben wird. In diesem Fall würden die Repository-Klassen nicht zu EF passen.

Wechsel zum Business-Objekt-Layer - hier erstellen Sie ein Modell der Business-Domäne mit Datenklassen, Validierungsklassen und Prozessklassenmodellen.Eine Prozessklasse zum Aufzeichnen eines Kundenauftrags könnte beispielsweise Datenkonzepte eines Geschäftskunden, Geschäftskundenauftrags, Geschäfts-Produktkatalogs und eine Reihe von Validierungsklassen kombinieren, um einen einzelnen atomaren Geschäftsprozess zu bilden. Diese Klassen könnten (wenn Sie eine sehr einfache Anwendung ausführen) den Daten auf der Repository-Ebene ähnlich sein, sie sollten jedoch separat definiert werden. In dieser Ebene haben Sie berechnete Konzepte wie "Kundenauftragssumme" oder "Umsatzsteuerberechnung" oder "Versandkosten". Sie können oder werden möglicherweise nicht in Ihrem Repository gespeichert, aber die Definition dessen, was sie bedeuten, wird in der Business-Schicht modelliert.

Die Business-Schicht stellt die Klassen bereit, deren Daten in ein View-Modell kopiert werden. Diese Klassen wiederum können den Repository-Klassen sehr ähnlich (und in den einfachsten Fällen identisch) sein, aber in ihrer Aufgabe ist es, die Benutzerschnittstelle und Benutzerinteraktion zu modellieren. Abhängig von den Anforderungen der Benutzeroberfläche enthalten sie möglicherweise nur einige Daten aus den Geschäftsdatenklassen. Diese Klassen sollten eine benutzeroberflächenbasierte Validierung durchführen, die sie an die Geschäftsebene delegieren können, oder eine zusätzliche Validierung hinzufügen. Die Aufgabe dieser Klassen besteht darin, die Zustandsmaschine zu verwalten, die die Benutzerschnittstelle ist.

Meine Zusammenfassung ist, dass in einem großen System haben Sie drei Sätze von Klassen; Daten Repository Interaktion, Business Model Interaction und User Interface Interaction. Nur in den einfachsten Systemen werden sie als eine einzige Menge physischer POCO-Klassen modelliert.