Dobre praktyki .NET

Skromny Kret napisał(a):

somekind napisał(a):

Błękitny Orzeł napisał(a):

I ma Update?

Ma Select i Insert ;)

No to jednak nie repozytorium.

somekind napisał(a):

Błękitny Orzeł napisał(a):

Tak chodziło mi o to, że repozytorium operuje na Aggregate roocie.
A jeśli jeden agregat ma w sobie innego?

To wtedy nie jest to DDD, więc nie jest aggregate rootem.

Metoda update robi w zależności od implementacji

1. Zamienia obiekt w kolekcji w przypadku InMemory

Ale co zamienia? Jeśli jest w pamięci, to wystarczy przecież przypisać nową wartość i już jest zupdatowana.

Tak wiem, że wystarczy zmienić ale chodziło mi o to, że mam interfejs repozytorium i różne implementacje. Więc chcę by serwisy korzystały z kontraktu a implementacje podmieniam.

1. Wysyła POST do mikroserwisu za pomocą klienta wygenerowanego przez AutoResta - a co dalej się dzieje to nie wiem. Może sql.

Tak od razu? Bez UoW? Bez transakcji? To nie DDD.

Tak. Jakiej transakcji? UoW dla jednego repo?
Wygląda to tak, że otrzymuje request do WebApi stąd wysyłam komendę do Serwisu, który modyfikuje obiekt domenowy i wywołuje metodę update repozytorium.
Po co tutaj UoW i transakcje?

Ogólnie projekt, na którym bazuje w tym temacie to wielka fasada do paru mikroserwisów(z których korzystam tylko ja :P (póki co!! - może kiedyś inny system będzie chciał)) oraz wystawiam WebAPI dla klineta Angularowego.
Powiedziano mi by zrobić to w DDD(więcej napiszę spoza kompa firmowego :P).

Jesteś nowy w tej pracy? Bo może to głupi dowcip dla świeżaka miał być...
No bo jeśli nie, to ktoś tam ewidentnie się z własnym przyrodzeniem na łby pozamieniał. DDD ma zastosowanie w projektach ze skomplikowaną logiką biznesową. Ty masz fasadę, więc nie masz żadnej logiki biznesowej, to jest idealny przykład miejsca, w którym DDD się nie uda nawet na siłę.

Wszystkie solucje/projekty w tym systemie mają być pisane w DDD. Fasada, mikroserwisy, nawet front w TypeScript :P
Oczywiście wygląda to tak, że bez żadnego głębszego szkolenia odnośnie DDD. Po prostu Aggregate Rooty, bez ValueObject bo nie widzimy gdzie by je wcisnąć. CQRS(eventy tylko lokalnie! :P) modyfikuje obiekty domenowe(z projektu Domain) i wywołuje metody repo.

Więc przykryłem metody klienta jedną metodą Update, które wykonywane są w zalezności o typu zdarzenia.
Wydaje mi się, że jest to takie trochę ubogie CQR gdzie manualnie(w kodzie) żągluje zdarzeniami.

Czy to jest dobre repozytorium, które ukrywa źródło danych?

Nie, to nie jest żadne repozytorium. To jest po prostu zwykła fasada.
Ale dobra fasada? :P

Okej, widzę, że dużo mam do nauki.
Repozytorium - jak powinno wyglądać, kiedy to nie jest repo a kiedy jest.
DAO - ??
UoW / transakcje

Mam projekty:
Model(modele),
Contracts(viewmodele, interfejsy serwisów),
Application (implementacje serwisów),
Web(widoki i kontrolery).
Gdzie umieścić DbContext, który będę wstrzykiwal do serwisów?

Błękitny Orzeł napisał(a):

Tak wiem, że wystarczy zmienić ale chodziło mi o to, że mam interfejs repozytorium i różne implementacje. Więc chcę by serwisy korzystały z kontraktu a implementacje podmieniam.

I próbujesz pokonać naturalne działanie języka przy pomocy jakiejś pokrętnej architektury?

Tak. Jakiej transakcji? UoW dla jednego repo?
Wygląda to tak, że otrzymuje request do WebApi stąd wysyłam komendę do Serwisu, który modyfikuje obiekt domenowy i wywołuje metodę update repozytorium.
Po co tutaj UoW i transakcje?

No jak nie ma miejsca na UoW i transakcje biznesowe, to tym bardziej nie ma go na DDD i repozytoria.

Wszystkie solucje/projekty w tym systemie mają być pisane w DDD. Fasada, mikroserwisy, nawet front w TypeScript :P
Oczywiście wygląda to tak, że bez żadnego głębszego szkolenia odnośnie DDD. Po prostu Aggregate Rooty, bez ValueObject bo nie widzimy gdzie by je wcisnąć. CQRS(eventy tylko lokalnie! :P) modyfikuje obiekty domenowe(z projektu Domain) i wywołuje metody repo.

Tylko, że to z DDD nie ma nic wspólnego.

Wielki Młot napisał(a):

Mam projekty:
Model(modele),
Contracts(viewmodele, interfejsy serwisów),
Application (implementacje serwisów),
Web(widoki i kontrolery).
Gdzie umieścić DbContext, który będę wstrzykiwal do serwisów?

Ten Model to co to za modele? Biznesowe czy EF? Bo jak EF, to DbContext równie dobrze możesz mieć tam. A jeśli nie, to do DataAccess albo Infrastructure.

@somekind trochę odbiegnę od waszej dyskusji, ale co sądzisz o EF Corze? Osobiście w pracy stosujemy Dappera (jestem juniorem, więc dał mi kopa do skilla w SQL, za co go sobie chwalę), ale z ciekawości popatrzyłem na ten nowy twór EF Core i według kilku benchmarków dorównuje dapperowi.

DEFINETRUEFALSE napisał(a):

@somekind trochę odbiegnę od waszej dyskusji, ale co sądzisz o EF Corze? Osobiście w pracy stosujemy Dappera (jestem juniorem, więc dał mi kopa do skilla w SQL, za co go sobie chwalę), ale z ciekawości popatrzyłem na ten nowy twór EF Core i według kilku benchmarków dorównuje dapperowi.

Z tym dorównuje to bym nie przesadzał, różnica ciągle jest spora 343.6 us vs 233.2 us:
https://www.reddit.com/r/csharp/comments/6yhp84/entity_framework_core_20_vs_dapper_performance/
aczkolwiek idzie to zdecydowanie w dobrą stronę, tyle że niestety póki co efc nie wspiera mapowania czystego sql na obiekty inne niż te używane z DBSet<T>, więc raczej bez Dappera się nie obejdzie.

DEFINETRUEFALSE napisał(a):

@somekind trochę odbiegnę od waszej dyskusji, ale co sądzisz o EF Corze?

Nic nie sądzę - nie używam Core.

Jak korzystać z obiektów DTO? Jeżeli wyciągam całą kolekcję obiektów z repozytorium dobrym podejściem będzie przepisanie tego do DTO w serwisie w pętli?

Jeśli potrzebujesz DTO, to po co Ci w ogóle jakieś repozytorium i mapowanie, nie prościej od razu wyciągnąć to DTO?

Co myślicie o logice aplikacji w bazie? Mam na myśli if'y, case'y w procedurach. Z tego co widzę i słyszę nie jest to rzadkie zjawisko w .NET.

Ta choroba dotyczy ludzi, którzy zatrzymali się w rozwoju w latach osiemdziesiątych. Każdy zdrowo myślący człowiek woli pisać kod, który się da łatwo testować, debugować i wersjonować, SQL takim nie jest.

Na upartego da się i wersjonować i testować i debugować (przynajmniej mssql) logikę trzymaną w bazie, no ale powinna to być wyłącznie ostateczność, wtedy i tylko wtedy kiedy mamy co najmniej rząd wielkości pod względem wydajności do zyskania w stosunku do logiki trzymanej w kodzie. Bo logikę trzymaną w kodzie znacznie łatwiej utrzymać.