Cześć,
Od jakiegoś czasu mam sytuacje, która być może blokuje mnie jako programistę. Moim głównym stackiem jest ASP.NET Core WebAPI + jakiś framework UI. Zostawmy UI na razie. Pracuje z nim prawie 3 lata, w międzyczasie dość sporo sie nauczyłem - od EF Core, po cachingu, logging frameworks,REST, mappery, background taski, testy etc.
Miałem głównie do czynienia z projektami w których był dość klasycznie CQRS, MediatR, Clean/Onion architecture, Repository pattern itd. I dochodząc do meritum - praktycznie w ogóle nie użyłem żadnych design patternów. Z 2x może buildera, 1x fabrykę. I to koniec. Zastanawia mnie - czy ktoś z was w WebAPI w ogóle korzysta z tych innych jak Facade, Composite, Decorator etc. czy są to jednak pozostałości z dawnych czasów bądź nie mają zastosowania do nowoczesnej webówki?
Michu21 napisał(a):
Zastanawia mnie - czy ktoś z was w WebAPI w ogóle korzysta z tych innych jak Facade, Composite, Decorator etc. czy są to jednak pozostałości z dawnych czasów bądź nie mają zastosowania do nowoczesnej webówki?
Ja korzystam, zwłaszcza po to żeby oddzielić logikę biznesową od frameworka.
To co piszesz,
Michu21 napisał(a):
Pracuje z nim prawie 3 lata, w międzyczasie dość sporo sie nauczyłem - od EF Core, po cachingu, logging frameworks,REST, mappery, background taski, testy etc.
sugeruje jakbyś patrzył na swoją aplikację przez pryzmat frameworka, jakby framework był "centrum" Twojej aplikacji, zamiast myśleć o nim jak o szczególe implementacyjnym (tak jak się powinno IMO).
Bo design patterny nie są po to, żeby je pchać na siłę.
Jeśli korzystałeś z MediatR to mediatora czy command używałeś nawet nie wiedząc o jego wewnętrznej implementacji.
Każde użycie abstrakcji w klasie jako private membera też po części można się połasić, że to bridge albo policy. Użyłeś ich zapewnie kilka, tylko nieświadomie.
Ponadto, część wzorców jest już trochę obsolete z racji nowych funkcjonalności języka, jak np. pattern matching.
Jak chcesz coś nowego i ciekawego, to może DDD i Event Sourcing? Może mikroserwisy - Docker, Docker Compose i networking całości?
Ja właśnie czytam ebooka o DDD i ES i ciekawy temat jest, ale podejrzewam, że marginalna ilość systemów jest napisana w ten sposób.
Michu21 napisał(a):
Miałem głównie do czynienia z projektami w których był dość klasycznie CQRS, MediatR, Clean/Onion architecture, Repository pattern itd. I dochodząc do meritum - praktycznie w ogóle nie użyłem żadnych design patternów. Z 2x może buildera, 1x fabrykę. I to koniec. Zastanawia mnie - czy ktoś z was w WebAPI w ogóle korzysta z tych innych jak Facade, Composite, Decorator etc. czy są to jednak pozostałości z dawnych czasów bądź nie mają zastosowania do nowoczesnej webówki?
Fasada bardzo często, bo bardzo często integruję się z różnymi zewnętrznymi API.
Dekorator dość rzadko, bo rzadko potrzebuję rozszerzać funkcjonalność klasy w biegu.
Najczęściej zdarza się strategia, łańcuch zobowiązań i budowniczy.
rjakubowski napisał(a):
Bo design patterny nie są po to, żeby je pchać na siłę.
Jeśli korzystałeś z MediatR to mediatora czy command używałeś nawet nie wiedząc o jego wewnętrznej implementacji.
Mediatora nie używał, bo biblioteka MediatR nie ma związku z wzorcem mediator. (To jest command dispatcher.)
Trochę mi się nie klei twoja wypowiedź bo wymieniasz Onion/Clean Architecture w jednym zdaniu z komponentami frameworka webowego: cache, mappery, orm, background taski czyli pewnie zadania oparte o interfejs IHostedService, itd. Jak używasz którejś z architektur jak Clean/Onion/Ports&Adapters to framework, a szczególnie framework webowy jest dla core systemu szczegółem implementacyjnym a dokładnie częścią infrastruktury tak jak pisze @Riddle Dobrze jest to zilustrowane na poniższym obrazku - Core aplikacji nie wie nic o otaczającym go świecie (GUI, REST, kolejki wiadomości, bazy danych, itd)
Twój brak doświadczenia może wynikać z niewielkiej złożoności funkcjonalnej aplikacji przy których pracowałeś, dlatego nie potrzebowałeś takich wzorców jak: Chain Of Responsibility, Proxy, Facade w tym ACL, Adapter czy Strategy. I dobrze bo wzorce należy używać tam gdzie rzeczywiście mają sens, a nie na siłę i robić sztukę dla sztuki.