@RoboCat @somekind @Klojtex
- Jeśli chodzi o repozytoria to jest to często źle rozumiany koncept, repozytorium jest implementacją idei Inversion of Control w SOLID a zatem:
"High-level modules should not depend on low-level modules. Both should depend on abstractions."
Taką formą abstrakcji od Entity Framework będącego "High-level module" jest repozytorium. Dzięki użyciu repozytorium jesteśmy w stanie odizolować wykorzystanie metod ORM'a od faktycznej logiki biznesowej i nawet wymienić ORM'a jak zmienią się wymagania co nie byłoby wykonalne gdybyśmy wszędzie mieli kwerendy linq'owe bijące do czystego context'u. Druga sprawa to czysty porządek. W tej architekturze repozytoria odpowiadają za enkapsulacje logiki chwytającej dane, serwisy za wykonywanie logiki biznesowej a kontrolery tylko wystawiają serie operacji. O wiele przyjemniej czyta się w kontrolerach coś takiego:
var partnerPayments = paymentRepository.getByPartnerId(partnerId);
var paymentSettlementResult = paymentService.settlePayments(partnerPayments);
if (paymentSettlementResult.IsValid) {
etc ...
}
aniżeli setki opatrzonych grubymi komentarzami kwerend linqowych lub co gorsza bicia do procedur na bazie. W ten sposób unikamy też dużej ilości duplikacji kodu bo po nazwach łatwo wnioskuje się że coś już istnieje i nie trzeba tego jeszcze raz pisać ;)
W tym kontekście, dobrze się czyta tych panów:
https://programmingwithmosh.com/tag/repository-pattern/
https://lostechies.com/jimmyb[...]ices-in-domain-driven-design/
Inna kwestia to zastosowanie izolacji tranzakcyjnej na poziomie aplikacyjnym przez użycie Unit of Work pattern, co pozwala zapewnić że wszystkie operacje wykonane w jednym requescie albo wszystkie sie powiodą albo wszystkie trafi szlag a nie że tranzakcje w połowie będą zapisywane do bazy bo developer przy użyciu contextu może sobie dowolnie zapisywać zmiany kilkukrotnie w jednym requescie. Repozytorium umożliwia wdrożenie UoW.
Nie jest prawdą że repozytorium to część DDD, repozytorium może być tak samo używane z ideą Event Sourcing'u w których modele domenowe jako takie mogą nawet nie istnieć, a źródłem danych są wyłącznie zdarzenia (fajnie współpracuje to z BDD). Są też rozwiązania które łączą wszystko razem z użyciem CQRS'a naprzykład. Co się tyczy konkretnej implementacji to zależy od Use Case'a, w niektórych małych aplikacjach bawienie się w zaawansowaną architekturę nie ma sensu i dodaje tylko complexity. W przypadku zmiany samego Generic Repository na proste Repository to jest to na liście poprawek od jakiegoś czasu w tym projekcie ;)
@Aventus @RoboCat @somekind @Klojtex
- Encje i modele Domenowe to jedno i to samo, w przypadku Entity Framework 6 z użyciem Code First reprezentowane pojedyńczymi klasami POCO oraz opcjonalną klasą konfiguracyjną pozwalającą nam zkonkretyzować jak ORM ma się zachowywać w danej situacji.
Co się tyczy EF, to jest to jedna z możliwych implementacji, równie dobrze można użyć innego ORM takiego jak nHibernate albo klasyczne relacje zdesignowac pod document model i chwycić po np Mongo albo RavenDB. Nie jest również prawdą że EF nie obsługuje ignorancji persystencji:
Lista providerów EF6: https://docs.microsoft.com/en-us/ef/ef6/fundamentals/providers/
Warto podkreślić że EF jest jednak ORM'em skupionym głównie na bazach relacyjnych, tak samo jak nikt raczej nie wymaga żeby MongoDriver nagle zaczął dobijać się do baz relacyjnych, tak nie oczekujmy że EF promowany jako Object Relational Mapper nagle zacznie bezkrytycznie współpracować tak z waszymi plikami płaskimi jak i bazami noSQLowymi.
Imho singleton nie jest anti-patternem, jest to natomiast pattern który jest dosyć nadużywany i przez to często mówi się o nim jako anti-patternie. W miejscach gdzie nie możemy pozwolić na to żeby w aplikacji istniały dwie różne instancje tej samej klasy lub chcemy zablokować możliwość równoczesnego dostępu do property singleton sprawdza się świetnie. Mówię tu chociażby o konfiguracji aplikacji czy dostępie do security. W praktyce wszystko zależy od case'a. Nawet Service Location może być wykorzystany w wyjątkowych sytuacjach poprawnie bez odnoszenia się do niego jako Anti-patterna.
@Hosap
Strasznie dużo nieuzasadnionej wyższości i arogancji w tym poście ale mimo wszystko postaram się odnieść (choć już widzę po komentarzach innych że mam do czynienia z trollem).
Nie wiem co rozumiesz przez nieodróżnianie Entity od ValueObject, ValueObject to wartość wbudowana wewnątrz entity czyli zamiast oddzielać coś do innej tabeli, przechowujemy jako compound type na innych tabelach zduplikowany. Najprostszym przykładem może być typ Money któremu samemu w sobie tabela się nie należy ale możemy przy jej pomocy zmodelować operacje na gotówce (monety etc) i fajnie żeby bez dodatkowej tabeli ta logika móc wykorzystać w poszczególnych encjach. I w ten właśnie sposób Value Object użyty jest w tej konkretnej implementacji.
Pozostałe rzeczy które powiedziałeś nie mają najmniejszego sensu. Mylisz też pojęcia, Monolith często nazywany lazanią jest typem architektury, tak jak typem architektury są mikroserwisy (I tak to repo to monolith). SOA i DDD natomiast to paradygmaty które można użyć w konkretnych typach architektury, DDD można użyć tak w Onion'ie jak i Mikroserwisach. Równie dobrze można zastąpić DDD, Event Sourcingiem albo użyć Event Sourcing w połączeniu z CQRS'em i DDD. Nie mają zbyt wiele wspólnego z samym typem architektury.
Nie ściemniaj, dobra. :P
Nie rozumiem? masz historię commitów na repo? Projekt zaczynałem dwa lata temu w celu dogłębnego zrozumienia rzeczy z którymi spotykałem się na co dzień na projektach w pracy i nie zawsze do końca rozumiałem zależności.
@Aventus @RoboCat @somekind @Klojtex @Hosap
Część implementacji może nie być optymalna bo dawno nie były revisitowane tak jak w przypadku braku podziału na Bounded Contexts czy użyciu Generic Repository gdzie klasyczne Repo starczyłoby. To tylko zbiór mający zobrazować jak wszystkie zasady wyglądają wspólnie i był moim polem eksperymentalnym w wielu wypadkach, nie wszystko jest perfect, fair enough, zapraszam do submittowania pull requestów albo podzielenia się własną pracą. Ja mam własną listę poprawek i na bieżąco ulepszam tą architekturę żeby ludzie mieli wgląd jak wygląda to wszystko razem i samemu też na bieżąco się czegoś uczyć.
