Wielomodułowa aplikacja webowa - projektowanie i dobre praktyki?

0

Jak tworzy się wielomodułowe aplikacje webowe w technologii asp.net z podziałem na warstwy: rest, database, domain itd.?
Po prostu dodając kilka projektów wewnątrz jednego rozwiązania(visual studio)? natomiast komunikacja pomiędzy tymi projektami następuje przy użyciu: using(...), tak?
w jaki sposób poprawnie projektować takie aplikacje? jakieś dobre praktyki?

0

To tak naprawdę zależy od wielkości projektu. Ale załóżmy, że apka ma być duża.
Więc ja mam kilka projektów w ramach jednej solucji:

  • model
  • dal
  • ewentualnie webapi
  • webapp

Do tego dochodzą osobne projekty z testami.

Tak to wygląda z grubsza. Dobrą praktyką jest to, żeby projekt Model nie wiedział nic o innych projektach. Najlepiej żeby nie był zależny od niczego (nie mówię tu o jakiś utilsach, czy helperach - wszędzie trzeba pomyśleć i podejść na zdrowy rozsądek). Generalnie model nie powinien mieć dostępu pośredniego, czy bezpośredniego ani do WebAPI, ani do DAL, ani do WebApp.

DAL ma mieć właściwie dostęp JEDYNIE do modelu
WebAPI korzysta z modelu i DAL
WebApp korzystać już może ze wszystkiego, ale jeśli używasz API, to WebApp nie powinno korzystać z DAL, tylko z WebAPI. Ale to już jest kwestia bardziej duplikacji kodu i porządku w nim.

0

natomiast komunikacja pomiędzy tymi projektami następuje przy użyciu: using(...)

Nie wiem co masz na myśli. using możesz użyć albo do importu namespace'ów albo do automatycznego zwolnienia zasobów. Jeśli poprzez "moduły" rozumiesz podział odpowiedzialności na konteksty biznesowe (np. orders, payments, stock) to warto zastosować komunikację przy użyciu wzorca Mediator. Wtedy moduły komunikują się między sobą za pomocą komand/poleceń oraz eventów/notyfikacji.

0
Juhas napisał(a):

Generalnie model nie powinien mieć dostępu pośredniego, czy bezpośredniego ani do WebAPI, ani do DAL, ani do WebApp.

Skąd model ma brać dane skoro ma nie mieć dostępu do warstwy persystencji?

0

@var Juhasowi chyba chodziło o Model w sensie encje. W przeciwnym razie model domenowy (czyli również logika biznesowa) mają **pośredni ** dostęp to DAL. Od tego jest dependency inversion oraz programowanie do interfejsów a nie implementacji.

0
var napisał(a):
Juhas napisał(a):

Generalnie model nie powinien mieć dostępu pośredniego, czy bezpośredniego ani do WebAPI, ani do DAL, ani do WebApp.

Skąd model ma brać dane skoro ma nie mieć dostępu do warstwy persystencji?

No ja tak robie. Mam warstwe z modelami odpowiednikami tabel w bazie. Potem warstwa dostepu do bazy (Ef) ktory widzi warstwe z modelami. I warstwa aplikacji ktora widzi warstwe z modelami oraz warstwe z dostepu do bazy. I ostatnia warstwa np api widzi warstwe aplikacji. I do tego uzywam mediatora

0

Tutaj jest pokazane co i jak zrobić :) chodziło mi o referencje do innego projektu(modułu)
https://stackoverflow.com/questions/44651629/referencing-another-project-in-net-core
Pobawię się przy użyciu architektury Onion

0

Tu jest pokazana dość popularna architektura, sądząc po ilości wyświetleń (jest też cały projekt na GitHubie).
Disclaimer: Nie twierdzę, że jest dobra/zła. Jedynie popularna. Do tego moim zdaniem trudno coś zepsuć przy takim podejściu, więc chyba w sam raz dla kogoś, kto dopiero zaczyna. Nie jest to programowanie obiektowe, więc pewnie nie każdemu się spodoba. No i raczej nie starczy do dużych systemów.

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