Repository Pattern UOW Dependency Injection Ninject

Question

ich Repository, Arbeitseinheit und Dependency Injection Muster in meiner Architektur Meine Ebenen:

Kern

Datalayer

BusinessLayer

ServiceLayer

In meiner Struktur, in der Einheit der Arbeitsklasse, stimmt etwas nicht wie oben

public class UnitOfWork:IUnitOfWork 
{ 
    private readonly IDataContext _context; 
    private IKullaniciDal _kullaniciDal; 
    private IKategoriDal _kategoriDal; 
    private IUrunDal _urunDal; 
    public UnitOfWork(IDataContext context) 
    { 
     _context = context; 
    } 

    public IKategoriDal KategoriDal => _kategoriDal ?? (_kategoriDal = new KategoriDal(_context)); 

    public IKullaniciDal KullaniciDal => _kullaniciDal ?? (_kullaniciDal = new KullaniciDal(_context)); 

    public IUrunDal UrunDal => _urunDal ?? (_urunDal = new UrunDal(_context)); 

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

hier möchte ich DataAccessLayers wie _kullaniciDAL

viel injizieren gesucht und ich sah einige Beispiele für die Erzeugung Repository genericly bu Ich möchte nicht von Unternehmen direkt auf die Repository-Instanz zugreifen zu können, möchte ich für den Zugriff Hier werden die Instanzen meiner KullaniciDal Klasse ist der Code von KullaniciDal

public interface IKullaniciDal : IRepositoryEntityFramework<Kullanici> 
{ 
} 

public class KullaniciDal : RepositoryEntityFramework<Kullanici>, IKullaniciDal 
{ 
    public KullaniciDal(IDataContext dbContextBase) : base(dbContextBase) 
    { 
    } 
} 

ich möchte einige von ihnen einige zusätzliche Funktionen zur Datenzugriffsschicht in speziellen schreiben und die Instanzen verwenden möchten als ein Teil der Einheit der Arbeitsklasse

Wie kann ich Dal Klassen injizieren? Seien Sie vorsichtig, dass ich Context-Objekt zu jeder Klasse dal

Answer 1

übergeben Es gibt ein paar Probleme, die ich hier sehe.

Zuerst wird die DAL selbst neu aufgebaut, anstatt von DI injiziert zu werden. Wenn Sie die DI-Route fahren, sind Sie besser dran, wenn Sie die DI einfach alles injizieren lassen und den Bereich der Objekte selbst verwalten lassen. Als eine Art allgemeine Regel, wenn Sie sich mit new() mit einer Infrastruktur-Klasse beschäftigen, machen Sie einen Schritt zurück und überlegen Sie, es zu injizieren.

public class UnitOfWork:IUnitOfWork 
{ 
    private readonly IDataContext _context; 
    public UnitOfWork(IDataContext context,IKullaniciDal kullaniciDal,IKategoriDal kategoriDal, IUrunDal urunDal) 
    { 
     KullaniciDal = kullaniciDal; 
     KategoriDal = kategoriDal; 
     UrunDal = urunDal; 
     _context = context; 
    } 

    public IKategoriDal KategoriDal{get;private set;} 

    public IKullaniciDal KullaniciDal{get;private set;} 

    public IUrunDal UrunDal{get;private set;} 

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

Die nächste Frage ist eher ein Design Frage. Warum werden all diese DALs von der UOW benötigt? Ich finde das merkwürdig.

Wenn ich eine Business-Schicht implementierte, die die UOW und eine DAL steuern musste, würde ich sie einfach in die Business-Schicht injizieren. sowohl durch das Repository/dll und die Einheit der Arbeit

public class FooBLL 
{ 
    private IKullanicDal _kullanicDal; 
    private IUnitOfWork _unitOfWork; 
    public FooBLL(IKullanicDal kullanicDal,IUnitOfWork unitOfWork) 
    { 
     _kullanicDal = kullanicDal; 
     _unitOfWork = unitOfWork; 
    } 

    public void FooBusinessMethod() 
    { 
     _unitOfWork.Begin(); 
     //do something with dal 
     //_unitOfWork.Commit etc 
    } 

} 

Es ist wahr, dass der Kontext ist erforderlich, wenn ein ORM wie EF verwenden, aber sie sind separate Muster. Ich würde Ihrem DI-Container erlauben, sowohl Ihren Kontext, Ihre UoW, Ihre BLL usw. angemessen zu erfassen, als auch, dass Sie sich keine Gedanken über die Weitergabe von Abhängigkeiten machen müssen, sondern dass der Container die Arbeit für Sie erledigt.

Dies hat auch andere SOLID-Design-Vorteile. Überlegen Sie, ob Sie einen HTTP-Filter implementieren, der Ihre Verbindung mit der http-Sitzung automatisch festschreibt. Der Filter muss nur über die IUnitOfWork-Methoden Commit, Rollback usw. Bescheid wissen. Es sollte von dieser minimalen Schnittstelle abhängen, es muss nicht über die DALs informiert werden.

Answer 2

Ich fand eine andere Lösung für die Erstellung von Repositories im laufenden Betrieb, wenn es benötigt wird. Es unterstützt auch mehrere Datenkontexte und es gibt einen weiteren Punkt, dass die IUnitOfWork-Schnittstelle IDisposable erbt. Der Code ist für EF Core v2.0. Hier ist das gesamte UnitOfWork.cs class code: