Pomoc w konfiguracji i architekturze solucji

Do tej pory pracowałem głównie .Net Frameworku i działałem na WCFach + kontrolery MVC w dużym uproszczeniu.
W ramach poznawania .NET Core 2.2 zacząłem sobie tworzyć szkoleniową apkę.
Potrzebuję kilka wskazówek odnośnie zaplanowania architektury takiej aplikacji. Mam jakąś wizję, ale nie wiem do końca jak to pożenić.

Mam na razie coś takiego:

BE.BusinessLogic - logika biznesowa i punkt styku z DB
BE.Data - Encje, DbContext, DbContextAdapter itp
BE.Infrastructure - w .NET Frameworku wrzucałem tu kontrakty, obecnie na razie wrzuciłem
WebApi - tutaj myślę sobie, że będę udostępniał na rzecz frontendu funkcjonalności logiki biznesowej za pomocą kontrolerów WebApi

FE.FamilyApp - ogólnie rzecz biorąc warstwa prezentacji i kontrolery MVC. I tu rodzi się pytanie. W przypadku projektów .NET Framework i WCF kontrolery MVC uderzały do serwisów WCF i udostępniały dane do widoków. Czy w przypadku mojego zamysłu, projektu powinno być podobnie? Tj. kontroler MVC na frontendzie uderza do WebApi backendowego? Będzie to miało ręce i nogi?

Druga kwestia tyczy się DI.
Rozumiem, że w projekcie FE.FamilyApp nie potrzebuję wstrzykiwania zależności gdyż kontroler MVC będzie wywoływał żądania http do web api?
Takiego autofaca instaluję tylko w projekcie WebApi, a wstrzykiwanie zależności w biblitekach klas będzie się odbywało za pomocą kontenera w projekcie WebApi?

Ja IOC zazwyczaj wydzielam do osobnego projektu. (Stylistyka kolejności budowania). Tak naprawdę jeżeli oddzielasz backend od frontendu to warstwą prezentacyjną są controllery w WebApi.
Teraz czy to podejście ma ręce i nogi? - Nie wiem. Ja tak robię i w domu i w pracy więc jest cień szansy :D
Tylko u nas za front robi zazwyczaj Angular dlatego dziwi mnie, że ktoś jeszcze chce używać WCF do frontu.
Moim zdaniem brakuje tez warstwy dostepu do danych. Samo Data powinno trzymać tylko encje.

Szekel napisał(a):

Ja IOC zazwyczaj wydzielam do osobnego projektu. (Stylistyka kolejności budowania).

I dajesz później referencje do projektu w którym jest klasa Program i Startup aby zainicjalizować silnik IOC?

Szekel napisał(a):

Tak naprawdę jeżeli oddzielasz backend od frontendu to warstwą prezentacyjną są controllery w WebApi.

Hmm, a co z kontrolerem MVC?
Bazując na obecnych wzorcach, które zastałem i na, których bazowałem to udostępnienie wszystkich metod z logiki biznesowej odbywało się za pomocą WCFów po stronie BE,
a kontroler MVC konsumował je po stronie FE.
Jako, że WebApi jest takim odpowiednikiem, zastępstwem WCFów z .NET Frameworka to próbuję ten wzorzec przełożyć podobnie na .NET Core.
Czyli w wielkim skrócie mam projekt z logiką biznesową, którego funkcjonalności po stronie BE udostępnia WebApi, a kontoler MVC po stronie FE je konsumuje i przekazuje do warstwy prezentacji.

Szekel napisał(a):

Tylko u nas za front robi zazwyczaj Angular dlatego dziwi mnie, że ktoś jeszcze chce używać WCF do frontu.

Tu będę chciał użyć Reacta za pomocą którego będę uderzał do kontrolera MVC + Bootstrap bo trochę go znam i ułatwia stylizację frontu. Jednak to w dalszej części. Na razie skupiam się na części BE.

Jeszcze takie jedno pytanie na boku...
Do tej pory służbowo miałem tak skonfigurowany projekt (nie wiem jak to się działo), że robią build solution wszystkie serwisy i strony z automatu publikowały mi się na iis.
Może mi ktoś podsunąć wskazówki jak to mogę sobie skonfigurować na swoim domowym środowisku?

Możesz sobie zrobić skrypty post-build (PPM na projekcie -> Properties), które będą robiły cokolwiek tylko chcesz dodatkowego po zakończeniu budowania twojej solucji.

Możesz też się zainteresować rozwiązaniami CI/CD, typu Azure DevOps czy inny Jenkins, gdzie też można sobie stworzyć różne rzeczy - ja np. w pewnym prywatnym projekcie mam, że po push na GitHuba buduje mi się projekt, odpalają testy, buduje kontener Dockera i jest wysyłany do prywatnego repozytorium.

A czemu w .NET Frameworku wszystkie aplikacje webowe czy wcfy z automatu się publikowały na lokalnym IIS w DefaultWebSite?
.NET Core różni się tym, że trzeba to oprogramować?

Moim zdaniem warto by sięgnąc pod pozycję od Microsoftu i zobaczyć jak można zrobić od razu coś na dockerze i w arch mikroserwisów:
https://dotnet.microsoft.com/learn/aspnet/microservices-architecture

altek napisał(a):

BE.Infrastructure - w .NET Frameworku wrzucałem tu kontrakty, obecnie na razie wrzuciłem

Kontrakty w Infrastructure? Ale czemu?

W przypadku projektów .NET Framework i WCF kontrolery MVC uderzały do serwisów WCF i udostępniały dane do widoków. Czy w przypadku mojego zamysłu, projektu powinno być podobnie? Tj. kontroler MVC na frontendzie uderza do WebApi backendowego? Będzie to miało ręce i nogi?

To jest podejście enerprise sprzed 10 lat. Można oczywiście tak zrobić, ale w takim układzie robisz przecież dwie osobne aplikacje (jedną MVC, drugą WebAPI), a co za tym idzie:

1. Możesz je separować fizycznie na różnych serwerach, niezależnie od siebie skalować, itp. Potrzebujesz tego? Bo jak nie, to po co?
2. Wypadałoby je mieć w oddzielnych solucjach.

Rozumiem, że w projekcie FE.FamilyApp nie potrzebuję wstrzykiwania zależności gdyż kontroler MVC będzie wywoływał żądania http do web api?

DI nie zależy od tego, co klasa robi, tylko od tego, czy ma zależności. Ten kontroler nie będzie miał żadnych zależności? Czy wszystkie będzie sobie sam tworzył?

Takiego autofaca instaluję tylko w projekcie WebApi, a wstrzykiwanie zależności w biblitekach klas będzie się odbywało za pomocą kontenera w projekcie WebApi?

Tylko wtedy WebApi musi mieć referencje do wszystkiego. Ja bym tak nie robił, ale się da.

altek napisał(a):

Tu będę chciał użyć Reacta za pomocą którego będę uderzał do kontrolera MVC + Bootstrap bo trochę go znam i ułatwia stylizację frontu. Jednak to w dalszej części. Na razie skupiam się na części BE.

A jak w Reakcie masz zamiar obsługiwać HTML wypluty przez MVC? I przede wszystkim po co?
Bo React może (a nawet powinien) uderzyć bezpośrednio po dane w formacie JSON do WebAPI, i żaden MVC po drodze nie jest potrzebny.

somekind napisał(a):

Kontrakty w Infrastructure? Ale czemu?

Nie wiem. Dołączyłem do zespołu developerskiego i taki wzorzec tam zastałem.

somekind napisał(a):

To jest podejście enerprise sprzed 10 lat. Można oczywiście tak zrobić, ale w takim układzie robisz przecież dwie osobne aplikacje (jedną MVC, drugą WebAPI), a co za tym idzie:

1. Możesz je separować fizycznie na różnych serwerach, niezależnie od siebie skalować, itp. Potrzebujesz tego? Bo jak nie, to po co?
2. Wypadałoby je mieć w oddzielnych solucjach.

Zgadza się. Aplikacja w firmie zaczęła być pisana ponad 10 lat temu i opiera się na wzorcach z tamtych lat. Dalej je stosują, a ja byłem na nie skazany.
Generalnie to robię ten projekt w celach szkoleniowych. Chcę liznąć .NET Core i WebApi.

somekind napisał(a):

Tylko wtedy WebApi musi mieć referencje do wszystkiego. Ja bym tak nie robił, ale się da.

W zasadzie to tak. Co byś zaproponował? Wszystko w jednym projekcie?

somekind napisał(a):

A jak w Reakcie masz zamiar obsługiwać HTML wypluty przez MVC? I przede wszystkim po co?
Bo React może (a nawet powinien) uderzyć bezpośrednio po dane w formacie JSON do WebAPI, i żaden MVC po drodze nie jest potrzebny.

Nie wiem w sumie :) Na razie mam plany aby liznąć Reacta i tak to sobie wymyśliłem. Próbuje to żenić ze wzorcami, które znam ze swojej firmy (patrz kilka linijek wyżej).
W sumie to myślałem żeby zapoznać się z konsumpcją WebApi od strony kodu w C#.
Czyli widzę to tak:
React -> kontoler MVC -> WebApi. I w drodze powrotnej leci wszystko w postaci JSONa.

altek napisał(a):

Nie wiem. Dołączyłem do zespołu developerskiego i taki wzorzec tam zastałem.

Infrastruktura, to raczej takie rzeczy ogólnego przeznaczenia, służące do obsługi plików, komunikacji przez sieć, operacji na tekście, tego typu rzeczy.
Generalnie cały .NET Framework jest infrastrukturą, jeśli robisz coś, co rozszerza możliwości frameworka (albo nawet jakichś innych bibliotek), to jest właśnie Twoja infrastruktura. W teorii to coś, co możesz przenieść do innego projektu i tam używać, bo jest uniwersalne i przydatne.
No, a kontrakty to coś stricte związane z biznesowymi aspektami aplikacji, którą tworzysz. To jest wręcz przeciwieństwo infrastruktury.

Zgadza się. Aplikacja w firmie zaczęła być pisana ponad 10 lat temu i opiera się na wzorcach z tamtych lat. Dalej je stosują, a ja byłem na nie skazany.
Generalnie to robię ten projekt w celach szkoleniowych. Chcę liznąć .NET Core i WebApi.

Skoro uczysz się nowych technologii, to nie powielaj architektur dopasowanych do starych technologii.

W zasadzie to tak. Co byś zaproponował? Wszystko w jednym projekcie?

Bynajmniej, sugeruję podzielić na moduły, każde assembly niech rejestruje swoje typy.

Nie wiem w sumie :) Na razie mam plany aby liznąć Reacta i tak to sobie wymyśliłem. Próbuje to żenić ze wzorcami, które znam ze swojej firmy (patrz kilka linijek wyżej).
W sumie to myślałem żeby zapoznać się z konsumpcją WebApi od strony kodu w C#.
Czyli widzę to tak:
React -> kontoler MVC -> WebApi. I w drodze powrotnej leci wszystko w postaci JSONa.

MVC jest frontendem, po co przykrywać jeden frontend innym?

somekind napisał(a):

Bynajmniej, sugeruję podzielić na moduły, każde assembly niech rejestruje swoje typy.

Czyli podział danych zagadnień, funkcjonalności na niezależne byty, które będą udostępniane przez WebApi?
Natomiast FE to oddzielna solucja składająca się z HTMLa i np frameworka JS z poziomu, którego uderza do danego WebApi po potrzebną mu funkcjonalność?

somekind napisał(a):

MVC jest frontendem, po co przykrywać jeden frontend innym?

No właśnie cały czas sobie wyobrażam, że kontroler MVC jest takim brzegowym mechanizmem uderzającym do BE.
Dajmy na to, że mamy sobie klasy zawierające logikę biznesową, która jest w projekcie typu biblioteka klas. No i żeby te funkcjonalności udostępnić to potrzebne jest jakieś narzędzie.
Jako, że WCFów już się nie używa to w zamian wchodzi WebApi?

altek napisał(a):

somekind napisał(a):

Bynajmniej, sugeruję podzielić na moduły, każde assembly niech rejestruje swoje typy.

Czyli podział danych zagadnień, funkcjonalności na niezależne byty, które będą udostępniane przez WebApi?

Chodzi bardziej o warstwy, które w Twojej solucji zapewne reprezentowane są przez projekty.
Ogólnie każdy projekt ma swój moduł, w module rejestrowane są typy z danego projektu. Projekt WebApi uruchamiając wczytuje wszystkie dllki projektów, i rejestruje moduły Autofaca.

Natomiast FE to oddzielna solucja składająca się z HTMLa i np frameworka JS z poziomu, którego uderza do danego WebApi po potrzebną mu funkcjonalność?

Nie wiem, czy solucja. To nazwa stosowana chyba tylko przez Visual Studio, a takiego FE raczej w VS się nie robi.

Dajmy na to, że mamy sobie klasy zawierające logikę biznesową, która jest w projekcie typu biblioteka klas. No i żeby te funkcjonalności udostępnić to potrzebne jest jakieś narzędzie.
Jako, że WCFów już się nie używa to w zamian wchodzi WebApi?

Tak, można zastąpić WCF przez WebAPI. Wtedy frontend zamiast komunikować się z WCF, komunikuje się z WebAPI. Nadal wystarczy jeden, a nie dwa frontendy.