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ł ?
0
1
A ile trwa obecnie build całości? Nie myślałeś aby oddzielić poszczególne moduły do oddzielnych solucji?
0
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 )
1
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.
0
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.
0
Ja zazwyczaj Utilsy globalne trzymam w projekcie Common, ViewModele w projekcie Contract. Jak wystawiasz Webowe API i możesz wydzielić moduły typu generowanie raportów w pdf. To możesz zrobić w ogóle oddzielny process.
Jeśli dochodzi potrzeba czerpania z innych niż baza źródeł danych to, to też do oddzielnych projektów
Jak nazywasz taki projekt ? Ja zazwyczaj, robie jeden Infrastructure i tam dodaje namespace na styl Port/Adapter
0
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ąć.
0
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.
0
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).
2
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.
2
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ą.
0
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ę.
0
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.
0
Dajcie przykład realny generycznego kontrolera i viewmodeli. Proszę.
Trzeba to jakoś konfigurować routingu czy gdzieś?
1
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.