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[...]hitectures#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 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0