Duży projekt MVC

Dzień dobry,
Pracuje nad sporym projektem MVC, niestety obecnie jego rozmiary stały już trochę uciążliwe gdy chce się przebudować projekt itd. I tutaj moje pytanie
jak sobie radzicie z takim problemem ? Oczywiście solucje podzieliłem na kilka mniejszych projektów np. App1, App2, App3, Repo itd i nie przebudowuje wszystkich tylko ten na którym wykonałem zmiany, oraz automatycznie przebudowuje się Repo. (każda z aplikacji ma referencje do Repo).
Powstało mi wiele klas DAO, czy wpakowanie ich w dll to dobry pomysł ?

A ile trwa obecnie build całości? Nie myślałeś aby oddzielić poszczególne moduły do oddzielnych solucji?

a jak proponujesz podzielić solucje ?
mam powiedzmy 3 główne warstwy a zarazem projekty
app1 (czyli kontrolery widoki itd )
Service ( serwisy które np. Zamieniają ViewModele na klasy modelu danych)
Repo ( klasy modelu danych oraz klasy Dao służące do odczytywania, zapisu do bazy danych )

Moim zadanie toniesz w bezsensownej złożoności, która nie wporwadza do projektu żadnej wartości. Powinieneś używać generyków i reflekcji do generycznych problemów. Niby po co ci wiele kas DAO? moim zdanie z dobrym ORM wystarczy jedna. Wydzielając między innymi politykę filtrowania można również mieć jeden serwis, który będzie czytał dane z DB i wypluwał ViewModele na podstawie zgodności typów, nazw i polityki requestów.

To zależy od złożoności, od tego co robi i od tego czy faktycznie jest problem z czasem builda.
Ale na moje oko, to jeśli chodzi o podział "poziomy", to ja zazwyczaj w oddzielnych projektach trzymam: modele ORM, logikę dostępu do danych, logikę biznesową, warstwę web, viewmodele, no i utilsy. Jeśli dochodzi potrzeba czerpania z innych niż baza źródeł danych to, to też do oddzielnych projektów, itd., itp.
Do tego dochodzi podział pionowy - na moduły wg pogrupowania w jakiejś funkcje, np.: sprzedaż, magazyn, księgowość, itd.

I tak jak nadpisał przedmówca - im więcej generycznych rozwiązań tym mniej kodu, tylko to wymaga umiejętności niedostępnych dla większości.

Dzięki za odpowiedzi :) może spróbuje znów wrócić do generyków ale ostatnio gdy próbowałem trochę nie mogłem tego ogarnąć.

ice25 napisał(a):

Dzięki za odpowiedzi :) może spróbuje znów wrócić do generyków ale ostatnio gdy próbowałem trochę nie mogłem tego ogarnąć.

Też tak pisałem na początku. Pomogła mi analiza tego jak działają frameworki i inne biblioteki. Równie dobrze możesz mieć też jeden generyczny kontroler zamiast kilku dla jednego generycznego serwisu wystarczy nadpisać fabrykę kontrolerów W ASP czy WPF.

Jeśli projekt jest aż tak duży że sprawia problemy to warto pomyśleć nad zmianą infrastruktury na system oparty o mikroserwisy. To wymaga zdefiniowania i podzielenia aplikacja na konteksty graniczne (ang. bounded context). Zaznaczając że każdy mikroserwis będzie wystarczająco duży, możesz tworzyć osobną solucję na każdy serwis.

Oczywiście każdy projekt w poszczególnych serwisach może posiadać referencje do dzielonej biblioteki głównej, która może posiadać modele oraz wspólną logikę (która powinna być ograniczona do minimum).

Jeśli projekt jest aż tak duży że sprawia problemy to próbujesz się z niego wykręcić, idziesz na urlop, zwolnienie, mówisz, że szukasz nowych wyzwań, zwalasz wine na innych itp.

Widzę że wygrało podejście generyczne, którego zwolennikiem nie jestem, także chciałbym oddać swój głos za modułami, znanymi także jako modularny monolit, czy też vertical slices, czy też najpierw podział wertykalny, a dopiero potem horyzontalny.

Mikroserwisy od samego początku zdecydowanie odradzam, zresztą hype na mikroserwisy powoli opada. Najpierw modularny monolit, a potem mikroserwisy/soa jeśli mamy jakiś problem który te mikroserwisy/soa rozwiązują.

neves napisał(a):

Widzę że wygrało podejście generyczne, którego zwolennikiem nie jestem, także chciałbym oddać swój głos za modułami, znanymi także jako modularny monolit, czy też vertical slices, czy też najpierw podział wertykalny, a dopiero potem horyzontalny.

Ale to się przecież w żadnym stopniu nie wyklucza. Generycznie można zrobić CRUDa, nie całą aplikację.

Widzę że wygrało podejście generyczne, którego zwolennikiem nie jestem

Jak to nie lubisz generycznego podejścia....!?
A kremówki lubisz?

Ale przecież on powiedział, że już ma tam takie jakby moduły ap1, ap2, ap3 ;), Jeśli mu to pomoże może z nich zrobić oddzielne solucje, które komunikowałyby się z core po http tylko pytanie, co z dostępem do danych, czy potrzebna by była jakaś warstwa middleware.

Dajcie przykład realny generycznego kontrolera i viewmodeli. Proszę.
Trzeba to jakoś konfigurować routingu czy gdzieś?

jacek.placek napisał(a):

Dajcie przykład realny generycznego kontrolera i viewmodeli. Proszę.
Trzeba to jakoś konfigurować routingu czy gdzieś?

np.
Web.Http.GlobalConfiguration

Tam możesz nadpisać, zamienić dowolny serwis w ASP. Reszta to już twoja intencja twórcza. Musisz znaleźć selector albo faktory dla kontrolerów.