Tworzenie abstrakcji nad MediatR

Odpowiedz Nowy wątek
2018-12-27 16:14
0

Czy warto tworzyć abstrakcję nad MediatR? Czy może jest to jedna z tych bibliotek, dla których nie warto, tak jak np. EF? A jeśli już tworzyć (bo projekt będzie duży), to jak? Przez pisanie interfejsów dziedziczących po interfejsach z MediatR i to ich implementowanie? Coś w stylu

public interface ICommandHandler<TRequest> : IRequestHandler<TRequest, Result> where TRequest : ICommand { }
public interface ICommand : IRequest<Result> { }

Do tego jakaś szyna opakowująca klasę Mediator, którą można by wstrzykiwać do kontrolerów.

edytowany 2x, ostatnio: nobody01, 2018-12-27 16:17

Pozostało 580 znaków

2018-12-27 16:22
3

Jeśli ma to sens to warto. Jeśli nie ma, to nie warto. Musisz sam sobie odpowiedzieć czy w Twoim projekcie taka abstrakcja będzie miała sens. Abstrakcja dla samej abstrakcji, bo tak było w jakimś tutorialu to jeden z częstszych błędów projektowania w ówczesnych projektach. W ogóle masz na myśli opakowanie całego frameworka czy jakichś jego części ? Jeśli części to pewnie znalazłeś już jakiś konkretny powód stworzenia tej abstrakcji.

Pozostało 580 znaków

2018-12-27 16:49
0

MediatR ma wszystko to, czego potrzebuję, a przynajmniej tak mi się wydaje. No może definicje klas requestów są zbyt rozwlekłe, jeśli chce się zwracać jakiś typ generyczny z handlerów: public class XCommand : IRequest<RequestResult<YModel>>.

Ludzie piszą, że należy tworzyć warstwę abstrakcji nad bibliotekami, które mogą w przyszłości zostać zamienione na inne. Ale przecież na początku projektu nie wiadomo, czy do biblioteki, której planuje się używać, nie wyjdzie w przyszłości jakaś lepsza alternatywa, więc należałoby pisać abstrakcję do wszystkich, które są używane w wielu miejscach. Jak żyć? :/

Pozostało 580 znaków

2018-12-27 17:27
4

No i przez takich ludzi powstała słynna abstrakcja na Entity Frameworku zwana repozytorium. Przy podmianie "core'owych" bibliotek powstanie wiele różnych innych problemów niż sam brak abstrakcji. Tego się po prostu prawie nigdy nie robi. Poza tym taką abstrakcje jest ciężko napisać lub jest to niemożliwe tak żeby przy podmianie biblioteki nie zaszła potrzeba robienia brzydkich hacków by wpiąć się w jej następce. Jedyny raz gdzie widziałem sens takiej abstrakcji to był sens biznesowy, gdzie jedno rozwiązanie było w chmurze (płatne) i nie wiadomo było, czy koszta sporo nie przewyższą kosztów utrzymywania darmowego odpowiednika. W tym przypadku wiadomo było, że może nastąpić podmiana. W przypadku biblioteki takiej jak Mediator nie widzę sensu takiej abstrakcji.

edytowany 1x, ostatnio: error91, 2018-12-27 17:28

Pozostało 580 znaków

2018-12-27 17:40
0

Jakie chcesz osiągnąć korzyści ze skorzystania z MediatR, bo jeżeli tylko dla zwiększenia loose coupling to może powinieneś się zastanowić nad innymi bardziej przystępnymi sposobami, wszystko zależy od złożoności projektu, być może taka abstrakcja nie jest potrzebna, ale jak najbardziej jest stosowana z powodzeniem. Myślę, że jednym z lepszych przykładów zastosowania MediatR to cqrs z event sourcing, bo miałem z tym doświadczenie, a poza tym to ciężko mi powiedzieć. W ogóle robisz to na poważnie, bo zwykle taką decyzje podejmuje cały team albo ktoś odpowiedzialny za projekt , kto miał z takimi rzeczami doświadczenie.

edytowany 2x, ostatnio: Visual Code, 2018-12-27 19:29

Pozostało 580 znaków

2018-12-27 17:44
0

@Visual Code: Używam MediatR do CQRS we własnym projekcie.

No to bardzo dobrze. Zawsze się czegoś nowego nauczysz i rozwiniesz. - Visual Code 2018-12-27 17:46

Pozostało 580 znaków

2018-12-27 18:26
0

@error91:

W ogóle po co ludzie używają Repo jeżeli nierzadko podmiana bazy ogranicza się do podmiany drivera?

edytowany 1x, ostatnio: WeiXiao, 2018-12-27 18:26
Na wypadek gdyby kiedyś chcieli zmienić EF na coś innego, czyli nigdy :) - mad_penguin 2018-12-27 18:43

Pozostało 580 znaków

2018-12-27 18:48
1

@WeiXiao: Bardziej tutaj chodzi o argument podmiany ORM'a. Podmiana bazy to już w ogóle hardcore na produkcyjnej aplikacji, na pewno nie tylko podmiana drivera. Odpowiadając na pytanie to ludzie używają różnych wzorców nie mając pojęcia jaki problem dany wzorzec rozwiązuje.

Pozostało 580 znaków

2018-12-27 18:49
0
error91 napisał(a):

@WeiXiao: Bardziej tutaj chodzi o argument podmiany ORM'a. Podmiana bazy to już w ogóle hardcore na produkcyjnej aplikacji, na pewno nie tylko podmiana drivera. Odpowiadając na pytanie to ludzie używają różnych wzorców nie mając pojęcia jaki problem dany wzorzec rozwiązuje.

W aplikacji podmiana drivera(no bo co jeszcze?) przy założeniu, że ten sam ORM, a na poziomie bazy export, odtworzenie schemy i jakoś przeniesienie danych :D

Wszystko chyba zależy z jakiej bazy na jaką - czasem jest łatwiej, a czasem trudniej :>

edytowany 3x, ostatnio: WeiXiao, 2018-12-27 18:52

Pozostało 580 znaków

2018-12-27 19:24
0
WeiXiao napisał(a):

@error91:

W ogóle po co ludzie używają Repo jeżeli nierzadko podmiana bazy ogranicza się do podmiany drivera?

Jeśli mowa o przypadkach gdzie stosują generyczne (lub nie) interfejsy, które tak naprawdę wystawiają dokładnie to samo na co pozwala czysty dostęp do kontekstu EF to faktycznie, jest to bez sensu. Natomiast jak najbardziej ma sens wyabstrachowanie EF, np. jeśli chcemy by nasz store/repository/cokolwiek dostarczał konkretnych kontraktów i zapobiegał samowolce w kodzie. Widok taki jak _context.SomeSet.Add(someObject) w różnych miejscach w kodzie jest dla mnie równie absurdalny co bezmyślne tworzenie repozytorium nie różniące się w zasadzie od czystego dostępu do kontekstu. Nie mówiąc już o stosowaniu zapytań na IQueryable gdzie popadnie (tutaj przydatne staje się użycie obiektów query które enkapsulują zapytania).

Co do sugestii odnośnie stosowania MediatR tylko po to by zwiększyć loose coupling- nie ma w tym nic złego i jest szeroko stosowane, a nazywa się to właśnie CQRS. Nie jest to CQRS na poziomie infrastruktury- gdzie moglibyśmy mieć oddzielny serwis do odczytu i zapisu- a CQRS w procesie. Nie zmienia to faktu że jest to właśnie CQRS które znaczenia ułatwia loose coupling, a poza tym pozwala na "odśmiecenie" kontrolerów. Dependency Inversion nie jest w żadnym razie alternatywą, a świetnym uzupełnień zastosowania MediatR. Zależności mogą zostać wstrzyknięte do handlerów.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.
Ucięło Ci sekcję [ponieważ] do części 1, dziwne... :P - WeiXiao 2018-12-27 19:44
Nie martw się, nie ucięło :) po prostu były to tematy już tyle razy wałkowane i oczywiste, że nie chce mi się na ten temat po raz N pisać esejów. Szczególnie jeśli miało by to rozpocząć dyskusje z Tobą, bez urazy ale parę razy już widziałem Twoje popisy na tym forum. - Aventus 2018-12-27 19:53
@Aventus: uu pocisk :D a które, bo jestem ciekaw - WeiXiao 2018-12-27 19:57
W żadnym razie pocisk, po prostu stwierdzam fakt. Nie będę teraz forum przeszukiwał, bez przesady :) - Aventus 2018-12-27 20:34
W żadnym razie pocisk, po prostu stwierdzam fakt to tak nie działa :D Jak Pani oddającej się na lewo i prawo powiesz "jesteś największą [hoe] na tym osiedlu" to nadal stwierdziłeś fakt oraz jej pojechałeś :) Niektórzy nawet się w ten sposób usprawiedliwiają, co jest w ogóle patologiczne - WeiXiao 2018-12-27 20:44

Pozostało 580 znaków

2018-12-27 19:42
0

@WeiXiao: No dokładnie to zależy. Przy zmianie z relacyjnej na relacyjną będzie mniej problemów niż z relacyjnej na jakiś NoSQL. Większość poza aplikacją, więc argument za repo, że abstrakcja nad ORM'em w czymś pomoże jest bez sensu bo masa większych problemów przy zmianie będzie poza aplikacją.

@Aventus: W większości przypadków "repozytorium" wygląda tak jak opisałeś w pierwszym zdaniu. Przynajmniej ja na takie trafiałem. Kod typu _context.SomeSet.Add(someObject) powinień być w serwisach aplikacyjnych i tyle. Jak wydzielisz samo _context.SomeSet.Add(someObject) to to jest właśnie ta niepotrzebna abstrakcja.

Jak najbardziej, problem tylko że ludzie często mówią o tym rodzaju abstrakcji - co mialo miejsce i tutaj - a brzmią jakby chodziło o wyabstrachowanie EF w każdym przypadku. To wprowadzanie w błąd. - Aventus 2018-12-27 19:55

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0