Jest sens tworzyć te interfejsy?

Mam aplikację podzieloną na kilka projektów. W projekcie Contracts znajdują się interfejsy typu IXXXViewModelProvider, IXXXStore, IXXXService, których implementacje są w w projekcie Application. Teoretycznie Web powinien mieć referencję tylko do Contracts. Ale w praktyce oddzielenie tego projektu od pozostałych części aplikacji za pomocą warstwy abstrakcji się nie udało, bo po wszystkich projektach są porozrzucane referencje do Microsoft.AspNet.Identity (w Web, bo AccountController, w Model, bo encja ApplicationUser, w Application, bo serwisy przyjmują za parametr obiekt IPrincipal, na którym często trzeba wykonać GetUserId()).

Pytania:

1. Czy istnienie tych interfejsów ma sens? Nie spodziewam się, aby którykolwiek z tych interfejsów miał więcej niż jedną implementację.
2. Jeśli w ogóle oddzielać Web od reszty warstwą abstrakcji, to co zrobić z systemem autentykacji? Zostawić jak jest, czy przepisać? Jeśli tak, to w jaki sposób?

To nie tak działa, poczytaj o SOA. Nie ma sensu oddzielać Application dodatkową warstwą, chyba że application musi mieć jakiś wspólny typ - interfejs z Web ale nie chcesz go trzymać w warstwie App.

Albo, jeśli Application jest częścią jakiegoś frameworka, który ma być autonomiczny względem web albo ogólnie Architektóra ma bazować na SOA, ale to nie w tym kontekście.

Poza tym powinieneś mieć kontekst jak Identity/Athorization.

Co ty chcesz ogólnie uzyskać tą warstwą? Może to ja nie rozumiem.

U @somekind ma to sens, bo w App nie powinien trzymać ViewModeli, dlatego ma jedną wspólną warstwę.

A, no tak. Nie napisałem, że w Contracts mam jeszcze ViewModele i DTOsy. Czyli co: wyrzucić interfejsy i tylko je zostawić? U somekinda jednak te interfejsy serwisów się pojawiają. Skąd mam wiedzieć, do których serwisów pisać interfejsy? o_O

Ok, wiem. Do tych serwisów, które pełnią tę samą funkcję na swój sposób. Ale w czym zmiana jednej linijki konfiguracji Ninjecta jest lepsza od dwóch kliknięć w R# czy czystym VS zmieniających "implementację" serwisu, z którego korzysta klasa? Aby podkreślić kontrakt realizujący serwis? Przecież jeśli napisany nowy serwis nie będzie spełniał kontraktu, to kod się nie skompiluje, więc w czym problem? Poza tym jeśli piszemy podobny serwis z intencją podmiany istniejącego, to przecież nie potrzebujemy interfejsu by określić, co dany serwis ma robić. Wystarczy spojrzeć na istniejący.

Oczywiście to są tylko moje rozważania, człowieka nie mającego pojęcia o tym, jak jest w "enterprise".

Skąd mam wiedzieć, do których serwisów pisać interfejsy? o_O

No w tamtym podejściu do wszystkich. Zobacz co to jest Contract w SOA

Ja tam wolę typowy Port - Adapter a ViewModel tworze tylko w szczególnych wypadkach jak muszę coś dodać po stronie View np Link, nazwę Hosta, etc... A jak chcę po prostu wysłać część tabeli z bazy do góry, to nazywam to CatDataResult albo CatResult.

nobody01 napisał(a):

Ok, wiem. Do tych serwisów, które pełnią tę samą funkcję na swój sposób. Ale w czym zmiana jednej linijki konfiguracji Ninjecta jest lepsza od dwóch kliknięć w R# czy czystym VS zmieniających "implementację" serwisu, z którego korzysta klasa? Aby podkreślić kontrakt realizujący serwis? Przecież jeśli napisany nowy serwis nie będzie spełniał kontraktu, to kod się nie skompiluje, więc w czym problem? Poza tym jeśli piszemy podobny serwis z intencją podmiany istniejącego, to przecież nie potrzebujemy interfejsu by określić, co dany serwis ma robić. Wystarczy spojrzeć na istniejący.

Oczywiście to są tylko moje rozważania, człowieka nie mającego pojęcia o tym, jak jest w "enterprise".

Nie widziałem tego co dopisałeś.

No tak, rozumiem o co ci chodzi. Wyobraź sobie, że interface jest po to żebyś mógł koledze wysłać paczkę i powiedzieć zaimplementuj sobie IPayService i wszystko powinno działać. W tamtym podejściu ten Contract wydaje się być trochę wybiórczym podejściem. ;-|. Ja bym go widział w innym zastosowaniu.

A ja też nie wiem jak jest w Enterprise. ;-|

Wydaje mi się, że do DI + do testów się przydają, albo żeby zrobić kolekcje obiektów różnego typu

np. w domyślnej templatce Cora jest coś w ten deseń.

services.AddScoped<IMyDependency, MyDependency>();
services.AddTransient<IOperationTransient, Operation>();
services.AddScoped<IOperationScoped, Operation>();
services.AddSingleton<IOperationSingleton, Operation>();
services.AddSingleton<IOperationSingletonInstance>(new Operation(Guid.Empty));

ale ręki nie dam sobie uciąć.

@._.: A, czyli chodzi o to, że interfejsy ułatwiają pracę w zespole? Pisząc jakiś serwis, mogę powiedzieć, jakich zależności potrzebuje poprzez właśnie interfejsy, i jakby nigdy nic pisać kod tego serwisu, mimo że interfejsy jeszcze nie mają implementacji?

nobody01 napisał(a):

@._.: A, czyli chodzi o to, że interfejsy ułatwiają pracę w zespole? Pisząc jakiś serwis, mogę powiedzieć, jakich zależności potrzebuje poprzez właśnie interfejsy, i jakby nigdy nic pisać kod tego serwisu, mimo że interfejsy jeszcze nie mają implementacji?

No dokładnie i najczęściej stosuje się wtedy Dependecy Inversion stąd te nazwy jak "DataProvaider". Interface najczęściej to jest coś co jest z zewnątrz. Chodzi też o to, że twój kolega nie musi używać tej samej bazy albo systemu płatności

Ja jeszcze tylko dodam od siebie na temat Identity- ogolnie nie lubie tego jak Identity narzuca pewne rzeczy, szczegolnie uzywanie ORM w postaci EF, nie to zebym cos mial do EF [pozdrawiam somekind'a ;)]. Pewnego dnia po prostu stworzylem wlasna implementacje wymaganych interface'ow (czy co tam trzeba podstawic, juz zapomnialem). Owszem, jest z tym chwilke roboty ale kiedy sie to zrobi to mozna pozniej uzyc ten sam kod w innych projektach, uzywac obiektow ktorych sie chce i jak sie chce (do pewnego stopnia oczywiscie) a jednoczesnie pozostawic dla Identity gros pracy takiej jak szyfrowanie danych itp. Polecam sprobowac, przy okazji mozna troche bardziej ogarnac strukture ASP.Net Identity.

Pewnego dnia po prostu stworzylem wlasna implementacje wymaganych interface'ow

Kto. przez to przechodził ten zrozumie ;-|

Ja jeszcze podpowiem, że możesz mieć jedną warstwę AppStart w której jest GlobalAsax i w każdym kontekście inną warstwę Web. Wtedy kontekst Identity obsługuje tylko reguły z nim związane. A reszta kontekstów używa tylko atrybutu [Authorize] a samo ASP staje się czymś w rodzaju MiddleWare.

nobody01 napisał(a):

Ale w praktyce oddzielenie tego projektu od pozostałych części aplikacji za pomocą warstwy abstrakcji się nie udało, bo po wszystkich projektach są porozrzucane referencje do Microsoft.AspNet.Identity (w Web, bo AccountController, w Model, bo encja ApplicationUser, w Application, bo serwisy przyjmują za parametr obiekt IPrincipal, na którym często trzeba wykonać GetUserId()).

No, ale to trzeba było oddzielić prawidłowo, a nie narzekać na forum, że się nie udało.

nobody01 napisał(a):

A, no tak. Nie napisałem, że w Contracts mam jeszcze ViewModele i DTOsy. Czyli co: wyrzucić interfejsy i tylko je zostawić? U somekinda jednak te interfejsy serwisów się pojawiają. Skąd mam wiedzieć, do których serwisów pisać interfejsy? o_O

Przy tym podejściu, do tych, które stanową publiczne API aplikacji.

To jest tylko propozycja architektury, w jednych przypadkach ma ona sens, w innych nie. Może się też nie podobać. Generalnie rozwiązuje problem separacji warstwy webowej od kodu aplikacji, ale to nie jest tak, że to jedyny sposób. Nie jest też tak, że taka separacja jest zawsze niezbędna.

nobody01 napisał(a):

@._.: A, czyli chodzi o to, że interfejsy ułatwiają pracę w zespole? Pisząc jakiś serwis, mogę powiedzieć, jakich zależności potrzebuje poprzez właśnie interfejsy, i jakby nigdy nic pisać kod tego serwisu, mimo że interfejsy jeszcze nie mają implementacji?

Chociażby.
Tylko w czasach, w których aplikacja to backendowe API + frontend w jakimś frameworku JS, jest mniejsze zapotrzebowanie na tego typu architekturę.

somekind napisał(a):

No, ale to trzeba było oddzielić prawidłowo, a nie narzekać na forum, że się nie udało.

@somekind ;) A jak Ty robisz system autentykacji użytkowników? Korzystasz z Identity, czy piszesz własny? A jeśli korzystasz, to jak dostosowujesz go do architektury swojej aplikacji? Masz może gdzieś przykładowy kod?

somekind napisał(a):

Przy tym podejściu, do tych, które stanową publiczne API aplikacji.

A co to jest publiczne API aplikacji? Masz na myśli klasy z projektu Application realizujące jakąs logikę biznesową/aplikacji?

nobody01 napisał(a):

@somekind ;) A jak Ty robisz system autentykacji użytkowników? Korzystasz z Identity, czy piszesz własny? A jeśli korzystasz, to jak dostosowujesz go do architektury swojej aplikacji? Masz może gdzieś przykładowy kod?

Nie korzystam z Identity, staram się nie pisać też własnego. Nieważne jaka implementacja jest użyta pod spodem, wystarczy jeden interfejs z implementacją w warstwie webowej, aby żadna logika w warstwach niżej nie musiała nic wiedzieć o żadnym "identity".

A co to jest publiczne API aplikacji? Masz na myśli klasy z projektu Application realizujące jakąs logikę biznesową/aplikacji?

Tak - te klasy, które de facto realizują przypadki użycia.