Ist es gut, alle Tabelleneigenschaften in der UOW-Klasse zu haben (generisches Repository-Muster)

Question

Ich arbeite am Asp.net MVC-Projekt. Ich folgte dem link, um generisches Repository zu erstellen.

public class UnitOfWork : IDisposable 
{ 

    private LeisureEntities context = new LeisureEntities(); 
    private IGenericInterface<cust_order> _customerOrderRepository; 
    private IGenericInterface<tblCustomer> _customerMasterRepository; 


    public IGenericInterface<cust_order> CustomerOrderRepository 
    { 
     get 
     { 
      return _customerOrderRepository = new GenericRepository<cust_order>(context); 
     } 
    } 

    public IGenericInterface<tblCustomer> CustomerMasterRepository 
    { 
     get 
     { 
      return _customerMasterRepository = new GenericRepository<tblCustomer>(context); 
     } 
    } 

    public void SaveChanges() 
    { 
     context.SaveChanges(); 
    } 



    private bool disposed = false; 

    protected virtual void Dispose(bool disposing) 
    { 
     if (!this.disposed) 
     { 
      if (disposing) 
      { 
       context.Dispose(); 
      } 
     } 
     this.disposed = true; 
    } 

    public void Dispose() 
    { 
     Dispose(true); 
     GC.SuppressFinalize(this); 
    } 
} 

Kann ich erklären alle Repositorys in UOW Klasse als Eigenschaften und dann direkt mit diesen UOW in der Steuerung oder Service-Layer verwenden. Das heißt, ich werde nur zwei Klassen in DAL 1 Generic Repository-Klasse und eine UOW-Klasse mit allen Eigenschaften von DB-Tabellen haben.

Muss ich separate UOW für jede Tabelle erstellen.

Ich benutze Datenbank ersten Ansatz.

Bitte vorschlagen.

Answer 1

Nein! Der Ansatz, UOW für alle Entitäten zu erstellen, ist ein sehr schlechter Ansatz. Aber die Idee, die Daten zu abstrahieren, ist gut.

Ich verwende ein GenericRepository für alle Entitäten. Dies ist der beste Weg, die Daten zu abstrahieren. Jedes Repository ist für Operationen an bestimmten Entitäten verantwortlich.

Dann extrahiere ich alle meine Geschäftslogik in Services -> Auf diese Weise wird die Geschäftslogik in einem Klassenbibliothek Projekt nach den SOLID-Prinzipien getrennt.

Jedes Objekt hat genau das, was es benötigt. Ich werde Ihnen ein Open-Source-Git-Repository zur Verfügung stellen, um meine Architektur zu überprüfen und wiederzuverwenden. Schauen Sie in einen Datenordner.

Der einzige Unterschied ist, dass Sie eine Datenbank zuerst Ansatz verwenden, und die Lösung besteht darin, den Db-Kontext mit einer partiellen Klasse zu erweitern.

Werfen Sie einen Blick darauf. Dies geschieht anhand der Best Practices. Es kann sehr einfach erweitert werden.

Mvc eshop architecture

......................................... .................................................. .................................................. ........................

Ja, die Architektur ist ein bisschen abstrakt und auf den ersten Blick zu komplex, denke ich, aber das löst dich super viele architektonische Probleme, bevor sie in der Zukunft geschahen. Ich werde Ihnen den einfachsten Service/Business-Logik/wie Sie wollten einfügen, damit Sie klarer verstehen können, was und warum es darum geht.

using Eshop.Data.Repositories; 

namespace Eshop.Services.Data 
{ 
using Contracts; 
using Eshop.Data.Models; 
using System.Linq; 

public class CategoriesService : ICategoriesService 
{ 
    private IRepository<Category> repo; 

    public CategoriesService(IRepository<Category> repo) 
    { 
     this.repo = repo; 
    } 

    public IQueryable<Category> GetAllCategories() 
    { 
     var categoriesToReturn = this.repo.All().Where(x => x.IsDeleted != true); 
     return categoriesToReturn; 
    } 

} 

In allen Diensten sollten Sie IQueryable zurückgeben und Ihre Abfrage kongestieren. In Ihren Controllern injizieren Sie den Dienst und den Webpart, wo die Controller nichts über Ihre Daten wissen. Wenn Sie den Service mit Inversionsumwandlung mithilfe von Ninject oder AutoFak injizieren, verwenden Sie diese Methoden und materialisieren das Abfrageergebnis in Ihrem Controller. Sie können sehen, wie ich den Dienst in den Home-Controller injiziere. Das Beste, was Sie tun können, ist, Automapper für Ihre Ansichtsmodelle zu verwenden und die Eigenschaften zu automatisieren. In diesem Fall bleiben Ihre Controller sauber und mit ein paar Zeilen Code. Sie erfüllen ihre Pflicht, die Anfrage zwischenzuspeichern, die Daten zu erhalten und sie an die Ansicht weiterzugeben. Ich hoffe, dass dir das nützlich ist. Mit diesem Ansatz können Sie einfach großartige, große Projekte erstellen, die schnell arbeiten und einfach zu unterstützen und zu ändern sind.Angenommen, Sie können die Datenbank sehr einfach ändern, eine Methode im Repository hinzufügen oder einfach eine andere benutzerdefinierte Aktion darin einfügen, wenn Sie beispielsweise alle Daten als geändert kennzeichnen möchten, wenn Sie sie per ID abfragen, dann müssen Sie nur in Ihre gehen GenericRepository und fügen Sie dieses Flag mit einer Zeile und voila :)