Problem ze zrozumieniem architektury .NET CORE MVC

0

Witam, tworzę prostą aplikację .NET Core MVC + EF Core.

Struktura Solution podzielona na projekty:
CORE:
-Encje
-DTOs
-Interfejsy

INFRASTRUCTURE:
-Konfiguracje encji
-Migracje
-Klasa Contextu
-Generyczne repo EfRepository<T>

WEB

TESTS

Zastanawiam się co dalej zrobić(1 vs 2 vs 3):

  1. Czy dla każdej encji mam tworzyć jej własne Repository (z interfejsem metod) i użyć tej abstrakcji w Controllerach projektu WEB? np. By żądać wszystkie osoby z bazy.
  2. Czy w stworzyć Domain Services dla każdej encji w CORE projektu, gdzie zdefiniuje proste operacje(CRUD w stylu getAll(), getByCondition(), ceate(), ...) dla danej encji. Następnie dodatkowa logika w App Services projektu WEB i dopiero użyć tej abstrakcji w Controllerach WEB?
  3. Czy po prostu użyć EfRepository<T> bezpośrednio w każdym z Controllerów.

Czym różnią się te podejścia? Docelowo chcę użyć jednej z tych abstrakcji w Controllerach. Jednak nie wiem, które z podejść jest słuszne i czy w ogóle rozumiem wymienione wyżej koncepcje. Czy może mi to ktoś wyjaśnić na przykładach? Zależy mi na czystej architekturze i modułowości aplikacji.

0

1, 2, 3 - nie używać repository...Twoją abstrakcją jest DbContext

0
boska_cebula napisał(a):

1, 2, 3 - nie używać repository...Twoją abstrakcją jest DbContext

Czyli mówisz że bezpośrednio w klasach kontrolera używać instancji klasy DbContext?

1
travis.chigurh napisał(a):

Czyli mówisz że bezpośrednio w klasach kontrolera używać instancji klasy DbContext?

Nie, już prędzej to co masz w pkt. 2 - "serwisy" i tam db context.

0
WeiXiao napisał(a):
travis.chigurh napisał(a):

Czyli mówisz że bezpośrednio w klasach kontrolera używać instancji klasy DbContext?

Nie, już prędzej to co masz w pkt. 2 - "serwisy" i tam db context.

Możesz podać przykład lub link do artykułu objaśniający tę koncepcje? Albo zapytam inaczej. Co robię źle i dlaczego?

4

@travis.chigurh:

Możesz zacząć od lektury pewnego boomera

http://commitandrun.pl/2016/05/30/Brutalne_prawdy_o_MVC/

0
WeiXiao napisał(a):

@travis.chigurh:

Możesz zacząć od lektury pewnego boomera

http://commitandrun.pl/2016/05/30/Brutalne_prawdy_o_MVC/

Dzięki, docelowo to nie będzie CRUD. Na razie po prostu chcę skonfrontować model z wymaganiami. Jak masz coś więcej to chętnie przeczytam. Nie musi być po polsku.

1

może to jako takie hinty jak to może wyglądać?

1
travis.chigurh napisał(a):

Struktura Solution podzielona na projekty:
CORE:
-Encje
-DTOs
-Interfejsy

Skąd pomysł, aby encje, DTO i interfejsy wrzucić do jednego projektu?
Czemu interfejsy w ogóle mają być w jakimś konkretnym projekcie?

INFRASTRUCTURE:
-Konfiguracje encji
-Migracje
-Klasa Contextu
-Generyczne repo EfRepository<T>

Infrastructure brzmi jak coś ogólnie przydatnego, a nie związanego stricte z określoną technologią przechowywania danych.

  1. Czy dla każdej encji mam tworzyć jej własne Repository (z interfejsem metod) i użyć tej abstrakcji w Controllerach projektu WEB? np. By żądać wszystkie osoby z bazy.

Dlaczego kiedykolwiek miałbyś pobierać wszystkie osoby z bazy?

0

@somekind: Dzięki za udział w dyskusji :)

Skąd pomysł, aby encje, DTO i interfejsy wrzucić do jednego projektu?
Infrastructure brzmi jak coś ogólnie przydatnego, a nie związanego stricte z określoną technologią przechowywania danych.

Sugerowałem się tym artykułem:
https://docs.microsoft.com/en-gb/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures#clean-architecture
Chętnie dowiem się jak to wygląda w praktyce (biznesie) a nie tylko na stronie dokumentacji :)

Czemu interfejsy w ogóle mają być w jakimś konkretnym projekcie?

Co do interfejsów to chodzi mi o te specyficzne dla encji. np ICreatedDate, które później implementuje BaseEntity. Myślę że jeśli wydzielę taki interfejs łatwiej będzie mi testować.

Dlaczego kiedykolwiek miałbyś pobierać wszystkie osoby z bazy?

Docelowo ma to być lista podzielona na strony. Dla uproszczenia robię na razie bez paginacji.

1
travis.chigurh napisał(a):

Sugerowałem się tym artykułem:
https://docs.microsoft.com/en-gb/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures#clean-architecture
Chętnie dowiem się jak to wygląda w praktyce (biznesie) a nie tylko na stronie dokumentacji :)

Szczerze, to ja nie wiem co to jest. Clean architecture wygląda tak:

screenshot-20201009203708.png

Źródło to oczywiście: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

Widać, że DTO, które są potrzebne dla controllerów/presenterów/gatewayów, ogólnie do komunikacji ze światem zewnętrznym nie mogą być wymieszane z encjami, które są w samym centrum.

A w praktyce, to zazwyczaj i tak jest encja na twarz i pchasz.

Co do interfejsów to chodzi mi o te specyficzne dla encji. np ICreatedDate, które później implementuje BaseEntity. Myślę że jeśli wydzielę taki interfejs łatwiej będzie mi testować.

Ok, czyli interfejsy dla domeny są w domenie, to jeszcze ma to sens. Jakoś nie wierzę jednak, aby to ułatwiało testowanie. Domena powinna być niezależna od świata zewnętrznego, więc co tam mockować w testach?

Docelowo ma to być lista podzielona na strony. Dla uproszczenia robię na razie bez paginacji.

Nie uważam, aby to było uproszczenie. Potem będziesz miał sporo do zmiany.

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