Posiadanie repozytorium zależne od innego repozytorium

Question

Niedawno spędziłem czas czytając na temat zasad SOLID i postanowiłem porównać porównanie bazy kodu, z którą pracuję.

W niektórych z naszych kodów znajduje się repozytorium (repozytorium A). Kiedy rekord ma zostać usunięty z repozytorium A, musimy również usunąć powiązany rekord z repozytorium B. Pierwotny koder stworzył więc zależność od konkretnej implementacji repozytorium B. Metoda w repozytorium A znajduje się w transakcji i usuwa rekord z repozytorium A, a następnie wywołuje metodę na repozytorium B, aby usunąć powiązane dane.

Moje zrozumienie zasady S polega na tym, że każdy obiekt powinien mieć tylko jeden powód do zmiany, ale moje repozytorium A ma 2 powody do zmiany? Czy jestem daleko od znaku?

Answer 1

Repozytorium powinno mieć jedną odpowiedzialność - utrzymywać jeden rodzaj podmiotu. Na przykład. pracowników. Jeśli musisz usunąć niektóre powiązane rekordy z innego repozytorium, wygląda to na logikę biznesową. Na przykład.

Kiedy pracownik jest zwolniony powinniśmy usunąć swój dziennik pracy

i zwyczajowe miejsce dla logiki biznesowej jest to usługi domeny. Usługa ta będzie miała zarówno repozytoriów i wykonać całą pracę:

staffService.Fire(employee) 

Wdrożenie będzie wyglądać

public class StaffService 
{ 
    private IEmployeeRepository employeeRepository; 
    private IWorkLogRepository workLogRepository; 
    private IUnitOfWorkFactory uowFactory; 

    // inject dependencies 

    public void Fire(Employee employee) 
    { 
     using(var uow = uowFactory.SartNew()) 
     { 
      workLogRepository.DeleteByEmployee(employee.Id); 
      employeeRepository.Delete(employee.Id); 
      uow.Commit(); 
     } 
    } 
} 

Więc podstawowy radzi

• starać się utrzymać swoją logikę biznesową w jednym miejscu, nie rozsyłaj jej części do interfejsu użytkownika, części do repozytoriów, części do bazy danych (czasami z powodu problemów z wydajnością, musisz wykonać trochę logiki po stronie bazy danych, ale to jest wyjątek)
• nigdy niech repozytoria odwoływać inne repozytoria, repozytorium jest bardzo komponent niskiego poziomu aplikacji z bardzo prostych zadań

Można zastanawiać się, co zrobić, jeśli masz pracownika i ma pewne zagnieżdżonego obiektu, który jest przechowywany w inna tabela bazy danych. Jeśli używasz tego obiektu oddzielnie od pracownika, wszystko jest jak wyżej - powinieneś mieć oddzielne repozytorium i jakiś inny obiekt (usługę), który manipuluje obydwoma repozytoriami. Ale jeśli nie użyjesz tego zagnieżdżonego obiektu osobno od pracownika, wówczas pracownik jest Korzeniem Aggregate i powinieneś mieć tylko repozytorium pracowników, które będzie sprawdzać obie tabele w środku.

Answer 2

W takim przypadku należy użyć wzoru event dispatcher.

Po operacja usuwania na RepoA można wysyłką zdarzenia jak:

dispatch repositoryA.deleted(RecordA) 

które przechowuje informacje o usuniętej rekordu.

Listing wentylacyjny następnie subskrybuje na takie zdarzenie i, mając repozytorium B jako zależność, wtedy wywoła usuwanie.

użyjmy B jak nazwa podmiotu, deklaracja słuchacz powinien brzmieć następująco:

Listen RepositoryA.delete and invoke onDelete(Event) 

Z takim podejściem zostały zrealizowane luźne sprzężenie pomiędzy repoA i repoB (wykonującego Open/Close zasadę - z bliska-) więc repoA mają teraz (znowu)

pozdrowienia.