Katalog Models w net.core mvc - pytanie zupełnie początkującego

0

Mam najgłupsze najpewniej pytanie świata.
Powoli sobie przechodzę przez różne tutoriale w "docs.microsoft" poznając sobie net.core MVC
I mam poważną zagadkę. Generalnie w katalogu models mam potworzone modele. Z czasem ich ilość narasta i przestaje to być dobrze widoczne.
Duża większość modeli odpowiada konkretnej tabeli DB. Sporo tabel jest ze sobą logicznie połączonych (w sensie, że są wspólnie zbiorem konkretnych danych na jakiś temat, niekoniecznie zaś w sensie relacji w nich samych), przykładowo Coś co nazywam obiekt, jest odzwierciedlone w DB w pięciu osobnych tabelach.
Pytanie brzmi, czy dla własnej wygody mogę sobie w katalogu Models potworzyć podkatalogi, a w nich grupować dopiero modele?
Szczerze, jedyne co mam na celu to przejrzystość tego co widzę.
Pewnie mój problem jest trywialny i wszyscy wszystko na ten temat wiedzą. I chyba dlatego mam ten problem i nie mogę nic na ten temat znaleźć.

2

Nie, nie powinieneś tworzyć podkatalogów. Powinieneś ten katalog w ogóle skasować, a modele umieścić w innych warstwach (projektach w solucji).

2

Te "Models" to modele widoku a nie Twoje modele domenowe (encje). Umieszczaj tam więc klasy które odpowiadają za to co i jak jest wyświetlane, a nie klasy modelujące warstwę biznesową. Tak jak somekind napisał, ich miejsce jest gdzieś indziej.

0

I teraz mam już namieszanie zupełnie :)
Wybaczcie, dla was to oczywistości wynikające z praktyki, dla mnie chaos który staram się ogarnąć.

Te "Models" to modele widoku a nie Twoje modele domenowe (encje). Umieszczaj tam więc klasy które odpowiadają za to co i jak jest wyświetlane, a nie klasy modelujące warstwę biznesową. Tak jak somekind napisał, ich miejsce jest gdzieś indziej.

Rozumiem z tego tyle, że Modele z katalogu Models mają być "zbiorem" danych do konkretnego widoku z katalogu Views i nie muszą w żaden sposób odzwierciedlać rzeczywistych tabel z DB?
Chwilowo przechodzę przez dwie opcje w tutorialach i w obu jest efekt odwrotny:

  • tworzenia DB z tego co mam w kodzie, właśnie w Models
  • Tworzenia kodu z tego co mam w DB tworząc Models

Obie te opcje działania albo tworzą DB z tego co w kodzie albo tworzą kod z tego co w DB. Obie są dla mnie dziwne i jakoś niezbyt przejrzyste. W obu efektem są modele odzwierciedlające DB.
Rozumiem, że finalnie mogę obie opcje (już po ogarnięciu tutoriali, bo jednak przejdę przez to do końca) wywalić na śmietnik i zacząć działać sobie zwyczajnie pisząc modele pod swoją bazę i oczekiwany efekt View?

Nie, nie powinieneś tworzyć podkatalogów. Powinieneś ten katalog w ogóle skasować, a modele umieścić w innych warstwach (projektach w solucji).

Hmm, staram się zrozumieć idee takiego działania i jedyne co mi przychodzi do głowy to fakt podzielenia całości na części, które funkcjonują i mogą być rozwijane niezależnie. Dobrze kombinuję? Czy stoi za tym inna prawda?

1
Yanno napisał(a):

Rozumiem z tego tyle, że Modele z katalogu Models mają być "zbiorem" danych do konkretnego widoku z katalogu Views i nie muszą w żaden sposób odzwierciedlać rzeczywistych tabel z DB?

Tak, to się nazywa viewmodel wtedy.

Chwilowo przechodzę przez dwie opcje w tutorialach i w obu jest efekt odwrotny:

  • tworzenia DB z tego co mam w kodzie, właśnie w Models
  • Tworzenia kodu z tego co mam w DB tworząc Models
    Obie te opcje działania albo tworzą DB z tego co w kodzie albo tworzą kod z tego co w DB. Obie są dla mnie dziwne i jakoś niezbyt przejrzyste. W obu efektem są modele odzwierciedlające DB.

Bo tutoriale nie pokazują jak tworzyć poprawną architekturę aplikacji, tylko jak użyć danej technologii. Z tego względu uproszają nieistotne w ich kontekście tematy, np. tego jak powinna wyglądać logika biznesowa czy przechowywanie danych.
Takie uproszczenie, że obiekt mapowany do relacji w bazie danych == obiektowi wysyłanemu do widoku jest akceptowalne w przypadku bardzo prostych, jednorazowych aplikacji, które nie mają skomplikowanej logiki, ani nie wyświetlają danych z jednej tabeli na wielu widokach. W przypadku bardziej skomplikowanych aplikacji takie podejście (zwane "encja na twarz i pchasz", sugeruję pogooglać) jest to prosta droga do poważnych kłopotów.

Rozumiem, że finalnie mogę obie opcje (już po ogarnięciu tutoriali, bo jednak przejdę przez to do końca) wywalić na śmietnik i zacząć działać sobie zwyczajnie pisząc modele pod swoją bazę i oczekiwany efekt View?

Owszem.

Nie, nie powinieneś tworzyć podkatalogów. Powinieneś ten katalog w ogóle skasować, a modele umieścić w innych warstwach (projektach w solucji).

Hmm, staram się zrozumieć idee takiego działania i jedyne co mi przychodzi do głowy to fakt podzielenia całości na części, które funkcjonują i mogą być rozwijane niezależnie. Dobrze kombinuję? Czy stoi za tym inna prawda?

0

Korzystając z życzliwości będę drążył dalej :)

Wstępnie jednak czas chyba na wstęp, aby wiadomo było co chciałbym osiągnąć i abyście wiedzieli, że macie do czynienia z kompletnym laikiem, który całkowity brak wiedzy nadrabia ciekawością, oślim uporem i ... przynajmniej się stara nadrabiać.
Mam sobie taki projekt, odnośnie mojej obecnej pracy. Wykorzystywany w tej pracy "system teleinformatyczny" ma sporo zalet (w zasadzie to że jest, jest jego zaletą) oraz wad (brak jakiejkolwiek elastyczności, co wiąże się z podstawową w przedsiębiorstwie kwestią - kosztami. Chcesz konkretny raport, zapłać nam a będziesz go miał. Sam go nie zrobisz, bo nie i nie jest dla nas ważne, że on CI jest potrzebny jednorazowo. Ważne abyś zapłacił). Nie mam nic przeciwko płaceniu za pracę, Jednak nie o tym tutaj. W efekcie stworzyłem sobie projekt, który ma być alternatywą. Oczywiście zdaję sobie sprawę, że porwałem się z motyką na słońce. I co z tego? Ciekawość mnie pcha do przodu i potrzeba sprawdzenia co z tego wyjdzie.
W tym kontekście usiadłem do SQL i stworzyłem sobie bazę danych. Po wielu zmianach, planach, przemyśleniach i kolejnych zmianach powstał sobie projekt bazy, który finalnie upchnąłem na darmowym azure od MS. Moja mocna strona - znajomość branży oraz umiejętność rozkładania dowolnej kwestii na "procesy" były tu dość pomocne. SQLa chwilowo tylko liznąłem i pogłębiam wiedzę w biegu, jednak z samej bazy jestem dość dumny. Chwilowo DB odzwierciedla tylko wycinek "projektu" - jakieś 20%, za to robi to dobrze, a jej rozbudowa o dalsze 80% będzie mam nadzieję bezproblemowa.
Nadszedł czas na ogarnięcie problemu w jakąś funkcjonalną całość. W pierwszym podejściu stworzyłem sobie excela, który to obsługiwał DB i wypluwał wyniki. Podejście to, choć w jakimś stopniu działa, nie sprawdzi się na dłuższą metę. A że już od dłuższego czasu chciałem do tego podejść od strony web, to poprosiłem google o pomoc, wyszło mi, że net mvc będzie w tym wypadku całkiem słuszną drogą. Świetnie się składa, bo od jakiegoś czasu bawię również się w poznawanie c#.
I tak oto jestem tutaj i szukam wiedzy dalej. Poziom który reprezentuję jest żenująco niski. Tak niski, że często nawet nie wiem o co pytać, aby poznać kierunek jakim warto iść. Żaden to wstyd, każdy kiedyś z tego poziomu startował :) Starczy tego wstępu.

Takie uproszczenie, że obiekt mapowany do relacji w bazie danych == obiektowi wysyłanemu do widoku jest akceptowalne w przypadku bardzo prostych, jednorazowych aplikacji, które nie mają skomplikowanej logiki, ani nie wyświetlają danych z jednej tabeli na wielu widokach. W przypadku bardziej skomplikowanych aplikacji takie podejście (zwane "encja na twarz i pchasz", sugeruję pogooglać) jest to prosta droga do poważnych kłopotów.

No dobrze. Wiem już, że należy do sprawy podejść inaczej. "encja na twarz i pchasz" przegooglowana. Wychodzi mi na to, że to co mi się w tutorialach ms niezbyt podobało, jest ogólnie rzecz biorąc podejściem, które warto poznać, ale nie zawsze warto używać. To teraz pytanie laika. Mam swoją bazę, chwilowo około 80 tabel z niewielką ilością danych testowych. Jak podejść do sprawy (w słowach dla debila) aby zrobić to dobrze? Nie tak, żeby działało, ale tak, żeby było zrobione zgodnie ze sztuką? Abym jeśli się już uczę, uczył się czegoś wartościowego?
Proszę o proste wskazówki, które z pomocą google będę mógł rozwinąć w wiedzę.

0

Czytam, szukam i ...
zastanawiam się czy dobrze rozumiem.

  • model odpowiada danym potrzebnym do danego widoku. - wychodzi mi z tego, że to w modelu mam ukrytą "logikę" tego jakie dane idą w danej chwili.
  • widok - wyświetla to co ma wyświetlać, czyli dane z konkretnego modelu.
  • kontroler - w tym wypadku służy w zasadzie tylko do przepychania danych pomiędzy modelem a widokiem i nie powinien zbytnio na te dane wpływać. Ma wybierać model i pchać go do widoku.

Czyli całość tego co, kiedy i w jaki sposób wyświetlam ustalam w zasadzie budując odpowiednie modele. To w nich mam ukrytą w zasadzie całą biznesową logikę, to tutaj powinna zapaść decyzja jakie dane są potrzebne?
Czy taka droga jest dobrym pomysłem? Czy w ten sposób powinno to działać?

0
Yanno napisał(a):

Czytam, szukam i ...
zastanawiam się czy dobrze rozumiem.

  • model odpowiada danym potrzebnym do danego widoku. - wychodzi mi z tego, że to w modelu mam ukrytą "logikę" tego jakie dane idą w danej chwili.
  • widok - wyświetla to co ma wyświetlać, czyli dane z konkretnego modelu.
  • kontroler - w tym wypadku służy w zasadzie tylko do przepychania danych pomiędzy modelem a widokiem i nie powinien zbytnio na te dane wpływać. Ma wybierać model i pchać go do widoku.

Czyli całość tego co, kiedy i w jaki sposób wyświetlam ustalam w zasadzie budując odpowiednie modele. To w nich mam ukrytą w zasadzie całą biznesową logikę, to tutaj powinna zapaść decyzja jakie dane są potrzebne?
Czy taka droga jest dobrym pomysłem? Czy w ten sposób powinno to działać?

Generalnie działa to tak, że model (encja) to klasa, na którą Entity Framework czy inny ORM mapuje ci tabelę bazy danych. Właściwości tego modelu odpowiadają kolumnom tabeli w bazie. Widok to wiadomo - prezentacja danych. Kontroler z jednej strony służy do przyjmowania żądań, z drugiej jak przychodzi żądanie, to trzeba zaimplementować logikę do jego obsłużenia zanim pchniesz dane do bazy. Pomiędzy kontrolerem i widokiem masz model widoku (ViewModel) i służy on jako taki pośrednik. Prosty przykład - masz aplikację, która ma dwie tabele np. Products i Categories. Na widoku produktu, chcesz klientowi pokazać z jakiej jest kategorii. W tabeli Products masz tylko klucz CategoryId, a nazwa kategorii jest w tabeli Categories. Nie pokażesz klientowi ID kategorii, bo nic mu to nie powie. I tu właśnie wchodzi model widoku - tworzysz sobie taki ViewModel, dajesz mu właściwości które chcesz wyświetlić czyli np. dwie właściwości typu Product i Category, w kontrolerze tworzysz instancję ViewModelu i do jego właściwości wpychasz sobie konkretny produkt i kategorię z bazy. Taki ViewModel przepychasz do widoku i wyświetlasz to co chcesz żeby użytkownik zobaczył.

3
gruby907 napisał(a):

Generalnie działa to tak, że model (encja) to klasa, na którą Entity Framework czy inny ORM mapuje ci tabelę bazy danych. Właściwości tego modelu odpowiadają kolumnom tabeli w bazie.

Generalnie takie jest powszechno-tutorialowe rozumienie tematu, ale nie jestem pewien czy na poważnym forum wypada takie rzeczy pisać.
W praktyce można mieć model z encjami, i nie mieć ORMa ani nawet bazy danych. Bo model/domena to to, co aplikacja robi, wszelkie procesy biznesowe oraz przetwarzanie danych. Ich przechowywanie to kwestia odrębna i czasami zbędna.

Kontroler z jednej strony służy do przyjmowania żądań, z drugiej jak przychodzi żądanie, to trzeba zaimplementować logikę do jego obsłużenia zanim pchniesz dane do bazy.

Niewątpliwie trzeba. Byle nie w kontrolerze.

Yanno napisał(a):

Czytam, szukam i ...
zastanawiam się czy dobrze rozumiem.

  • model odpowiada danym potrzebnym do danego widoku. - wychodzi mi z tego, że to w modelu mam ukrytą "logikę" tego jakie dane idą w danej chwili.
  • widok - wyświetla to co ma wyświetlać, czyli dane z konkretnego modelu.
  • kontroler - w tym wypadku służy w zasadzie tylko do przepychania danych pomiędzy modelem a widokiem i nie powinien zbytnio na te dane wpływać. Ma wybierać model i pchać go do widoku.

Czyli całość tego co, kiedy i w jaki sposób wyświetlam ustalam w zasadzie budując odpowiednie modele. To w nich mam ukrytą w zasadzie całą biznesową logikę, to tutaj powinna zapaść decyzja jakie dane są potrzebne?
Czy taka droga jest dobrym pomysłem? Czy w ten sposób powinno to działać?

Z grubsza tak, chociaż nie jestem pewien, czy dobrze rozumiesz. Model to dużo więcej niż dane. Niektóre klasy służą do komunikacji z kontrolerami, a niektóre do realizowania jakiejś logiki, a wszystkie te klasy znajdują się w modelu.

0
somekind napisał(a):

Niewątpliwie trzeba. Byle nie w kontrolerze.

Początkujący się takimi rzeczami nie przejmuje, dobre praktyki przychodzą z czasem. Na sam początek można sobie w kontrolerze implementować logikę, żeby zrozumieć jak działa całość. Do małych projekcików więcej nie potrzeba. Jak będzie robił większe projekty to sam zauważy że ważne jest zachowanie poprawnej struktury projektów w solucji, katalogów i separowanie zadań.

0

Trochę się mi naprostowało, mam nadzieję. Dziękuję za wszelkie wypowiedzi.

Model to dużo więcej niż dane. Niektóre klasy służą do komunikacji z kontrolerami, a niektóre do realizowania jakiejś logiki, a wszystkie te klasy znajdują się w modelu.

Właśnie w tym kontekście o tym pisałem. Bawię się teraz w prosty kalkulator wynagrodzeń aby sobie poukładać wiedzę ogólną na temat tego co gdzie i jak ... i właśnie mniej więcej tak to chciałem zrobić. Biorąc magiczny skrót MVC,
V - widok, wyświetlanie i pobieranie "od usera"
C- kontroler - działa pomiędzy widokiem i Modelem, w zasadzie to wychodzi mi na to, że jedynym jego zadaniem jest dopasowywanie woli usera do konkretnej drogi dalej, czyli odwoływanie się do odpowiedniego modelu.
M - model w tym rozumieniu miałby ... robić w zasadzie wszystko co potrzeba, czyli dostając z kontrolera informację, że potrzebna jest konkretna odpowiedź, ten skurczybyk odpowiedź tą wypracowuje. A jak to już zależy od samej idei programu. W każdym razie w modelu zbieram parametry przeliczenia składowych wynagrodzeń, przeliczam, w zależności od potrzeby i tego co chce user uzyskać za wynik, po czym wypluwam odpowiedź do kontrolera w ustandaryzowanej dla tego zagadnienia formie.

Prosty przykład - masz aplikację, która ma dwie tabele np. Products i Categories

Na prostym przykładzie się właśnie "wyłożyłem". Mam DB, która nie powstała (jak pewnie większość takich tworów) aby wspierać jedną apkę, a aby realizować dużo szersze zadania, z których bycie magazynem danych dla aplikacji to tylko niewielka część. I patrząc po tym, jak przedstawiają to tutoriale, powinienem zmienić całą DB, aby odpowiadała samej apce. Od samego początku podejście to wydawało mi się trochę nieracjonalne, żeby nie powiedzieć "głupie". W moim przypadku praktycznie zawsze, aby w końcu podesłać userowi view, muszę najpierw zebrać dane z wielu miejsc, przeliczyć je odpowiednio i dopiero wypchnąć dalej. I zdaje się, że w większości to właśnie robota dla modelu.
Zaczynam chyba pojmować o co warto powalczyć.

Początkujący się takimi rzeczami nie przejmuje, dobre praktyki przychodzą z czasem

Początkujący przejmuje się wszystkim. Niewiedza prowadzi właśnie do tego. Oczywiste dla Was jest dla mnie zagadką. Dlatego pytałem. A przy okazji początkujący mają problemy również z takimi tematami. Robię sobie właśnie kalkulator wynagrodzeń, który potem wepnę w powyższy problem. Uda się, jeśli od początku podejdę do sprawy dobrze. Nie uda się jak zrobię to na huraoptymizm.

Większość słowa pisanego w zakresie "dobrych praktyk" jest pisana w formie ciężkostrawnej dla początkującego. A szkoda, bo tematy są ciekawe, tylko ich zrozumienie jest początkowo trudne.
Że mi się na stare lata nudzić zaczęło, ech życie :)

Jeszcze raz dziękuję wszystkim.

3
gruby907 napisał(a):

Początkujący się takimi rzeczami nie przejmuje, dobre praktyki przychodzą z czasem. Na sam początek można sobie w kontrolerze implementować logikę, żeby zrozumieć jak działa całość. Do małych projekcików więcej nie potrzeba. Jak będzie robił większe projekty to sam zauważy że ważne jest zachowanie poprawnej struktury projektów w solucji, katalogów i separowanie zadań.

Z jednej strony masz rację, że dla początkującego to może być przytłaczające, ale z drugiej strony do wielu programistów jakoś te dobre praktyki nie docierają, nawet mimo długiego stażu. Dlatego ja jestem za tym, żeby dobrych praktyk uczyć się od początku. Może nie koniecznie w praktyce, ale przynajmniej o nich wspominać.

Yanno napisał(a):

C- kontroler - działa pomiędzy widokiem i Modelem, w zasadzie to wychodzi mi na to, że jedynym jego zadaniem jest dopasowywanie woli usera do konkretnej drogi dalej, czyli odwoływanie się do odpowiedniego modelu.

Generalnie tak.

M - model w tym rozumieniu miałby ... robić w zasadzie wszystko co potrzeba, czyli dostając z kontrolera informację, że potrzebna jest konkretna odpowiedź, ten skurczybyk odpowiedź tą wypracowuje. A jak to już zależy od samej idei programu.

Tak.

Większość słowa pisanego w zakresie "dobrych praktyk" jest pisana w formie ciężkostrawnej dla początkującego. A szkoda, bo tematy są ciekawe, tylko ich zrozumienie jest początkowo trudne.

No niestety, ciężko zrozumieć rozwiązanie abstrakcyjnego problemu, z którym się nie zmierzyło wcześniej samemu. Nie rozumie się rozwiązania, bo nie widzi się tego problemu.
Ale tak jest chyba ze wszystkim w każdej branży. No, a z drugiej strony, to wielu doświadczonych też nie widzi problemów nawet jeśli na nie natrafiają.

0

Czyli teraz droga wygląda mniej więcej tak, że:
Kontroler i widoki pozostają w starym projekcie i w wypadku potrzeby "dzwonią" po dane do nowego projektu "model".
Tworzę sobie ten nowy projekt, odpowiednik "model" i w nim realizuję wszelkie procesy niezbędne do pozyskania i obrobienia danych, które później idą albo nazad do kontrolera, albo gdzieś indziej ... w świat? Na przykład od DB?
Wychodzi mi na to, że model to realizacja domeny z DDD. Czy w takim wypadku nie powinienem odseparować z modelu w zasadzie wszystkiego innego?

  • Gdzie faktycznie realizować niezbędne połączenia ze światem zewnętrznym, z taką właśnie DB, z zapisem lub odczytem z plików itp itd? Istnieją w tym zakresie jakieś dobre praktyki?

Tak naprawdę to widzę, że wydzielenie modelu na początku drogi to żadna praca. VS zrobi większość roboty za mnie, a całość potrwa może z 30 min, albo i nawet nie tyle. Sama przejrzystość takiego układu przy małym projekcie wiele się nie zmienia, a nawet wydaje się lepsza, zwłaszcza gdy popatrzę na problem z punktu widzenia jego rozwoju i komplikacji. Wtedy mam jasny i czytelny podział całości.

  • I kolejne pytanie nooba. Gdzie w tym wszystkim tkwi zaleta takiego działania? Widzę dwie takie, ale może jest ich więcej. Sama czytelność jako pierwsza oraz modułowość jako druga. Ta modułowość mogłaby być kluczowa. Są jeszcze jakieś?
0
Yanno napisał(a):

Tworzę sobie ten nowy projekt, odpowiednik "model" i w nim realizuję wszelkie procesy niezbędne do pozyskania i obrobienia danych, które później idą albo nazad do kontrolera, albo gdzieś indziej ... w świat? Na przykład od DB?

W uproszczeniu tak.

Wychodzi mi na to, że model to realizacja domeny z DDD.

Można trzymać się DDD, a można i nie. Ja preferuję nie, bo to jest jakaś dziwna sekta kolorowych książek, a ja się od sekt trzymam z daleka. ;)

Czy w takim wypadku nie powinienem odseparować z modelu w zasadzie wszystkiego innego?

  • Gdzie faktycznie realizować niezbędne połączenia ze światem zewnętrznym, z taką właśnie DB, z zapisem lub odczytem z plików itp itd? Istnieją w tym zakresie jakieś dobre praktyki?

Ogólnie tak, tzn. model, infrastruktura, helpery, obsługa bazy danych - to powinny być oddzielne rzeczy. I wcale nie jest powiedziane, że te rzeczy muszą być w pojedynczych oddzielnych projektach. Równie dobrze model może byc rozbity na 20 projektów - wszyskto zależy od stopnia skompliowania i archiektury.

Przykłady to np. hexagonal architecture.

  • I kolejne pytanie nooba. Gdzie w tym wszystkim tkwi zaleta takiego działania? Widzę dwie takie, ale może jest ich więcej. Sama czytelność jako pierwsza oraz modułowość jako druga. Ta modułowość mogłaby być kluczowa. Są jeszcze jakieś?

Generalnie jak się wszystko wrzuci do jednego projektu, to potem każdej klasy można użyć wszędzie i z biegiem czasu powstaje kod-spaghetti, czyli takie wzajemne powiązanie klas, którego nie da się już naprawić, i dalsze rozwijanie oprogramowania staje się trudne.

0

Można trzymać się DDD, a można i nie. Ja preferuję nie, bo to jest jakaś dziwna sekta kolorowych książek, a ja się od sekt trzymam z daleka. ;)

Sekty mnie też niespecjalnie pociągają, Jednak nie patrzę na DDD w ten sposób. Chyba ze względu na mój poziom i sposób myślenia.
Generalnie dążę do zrozumienia idei, jaka przyświeca dowolnym "procedurom" postępowania. Dopiero to - zrozumienie idei początkowej oraz poznanie płynących z niej korzyści i wad pozwala na świadomy wybór w konkretnym przypadku. W moim świecie nie istnieją sztywne reguły postępowania, traktuję to raczej jako wskazanie drogi, którą mogę pójść. Kluczem jednak nadal jest zrozumienie samej idei. Tylko wtedy wybór będzie słuszny.

Wydaje mi się, że powoli zaczynam w tym natłoku znajdować jakiś sens i tym bardziej nie mogę na DDD patrzeć jak na sektę. Gdy teraz patrzę na to nieszczęsne DDD to widzę podstawową idee - tworzenie oprogramowania którego rozwój, zmiany i ogólne utrzymanie będzie "łatwym", niezależnie od zmian u "twórców" i u samego klient dla którego powstaje. I tak po prawdzie ma to sens, gdy się jest klientem i chce się zmienić "twórcę", lub gdy się jest "twórcą" i chce się zmienić "podtwórców". Wtedy koszty zmian mogą być zminimalizowane. Oczywiście, może to mieć również sens z poziomu "podtwórcy". Wejście w nowy projekt może być dużo łatwiejsze, naprawa lub zmiana ogranicza się do łatwych do identyfikacji fragmentów itp itd. Tylko nie wolno sobie pozwolić na drogę na skróty. Wspomniane przez Ciebie "hexagonal architecture" wygląda mi na realizację tej samej idei.
Ile w tym prawdy? przekonam się sam, tutaj już tylko praktyka pozwoli wyrobić sobie zdanie. Jednak sama idea odwzorowywania rzeczywistych procesów jakoś do mnie przemawia. Pytanie dlaczego? Czy fakt, że jako ledwo amator sam muszę ogarniać całość swoich projektów jest tutaj przyczyną?
Nie wiem jak to jest w realnym świecie przy pracy nad projektami. Czy np dostajesz do obrobienia wycinek całości, sprowadzony do prostego problemu który musisz wykonać? Wiesz co wchodzi, wiesz co ma wyjść i w wiesz co ma się dziać w środku, ale wiedza jak to ma funkcjonować w całości programu już Ci jest zbędna. Wtedy skupianie się na DDD nie za bardzo ma sens. Trochę to praca jak przy taśmie produkcyjnej u Forda. Po co się zastanawiać nad zarządzaniem fabryką, jak każą mi dokręcać śrubę.

@somekind - mógłbyś podesłać jeszcze kilka haseł zbliżonych do tematu? coś jak to "hexagonal architecture", abym miał co czytać? temat fajny i ciekawy, a w drodze do pracy mam sporo czasu na czytanie :). Z góry dziękuję.

2

Już rok temu interesowałem się mocno tematem - hexagonal architecture. Czytałem różne blogi i oglądałem prezentacje. Mogę polecić:

Poza hexagonal architecture możesz wyszukiwać informacji pod hasłami takimi jak: onion architecture, clean architecture ( taki sam tytuł ma dość popularna książka Robert C. Martina. Nie czytałem jej. Oglądałem jedynie prezentacje, w której Robert C. Martin poruszał, niektóre tematy. Wydaje mi się, że również wspominał on o hexagonal architecture, clean architecture oraz o książce Ivara Jacobsena).

2

odnośnie clean architecture warto też rzucić okiem na to:

2
Yanno napisał(a):

Wydaje mi się, że powoli zaczynam w tym natłoku znajdować jakiś sens i tym bardziej nie mogę na DDD patrzeć jak na sektę.

Nie chodziło mi oczywiście o to, że DDD samo w sobie jest sektą (bo przecież idea nie może być sektą), ile o to, że to podejście ma więcej fanatyków niż faktycznych użytkowników. Nawet na tym forum wielokrotnie zdarzały się interesujące dyskusje (chociaż to raczej monologi były) ludzi zaczytanych w różnokolorowych książeczkach.

Gdy teraz patrzę na to nieszczęsne DDD to widzę podstawową idee - tworzenie oprogramowania którego rozwój, zmiany i ogólne utrzymanie będzie "łatwym", niezależnie od zmian u "twórców" i u samego klient dla którego powstaje. I tak po prawdzie ma to sens, gdy się jest klientem i chce się zmienić "twórcę", lub gdy się jest "twórcą" i chce się zmienić "podtwórców". Wtedy koszty zmian mogą być zminimalizowane. Oczywiście, może to mieć również sens z poziomu "podtwórcy". Wejście w nowy projekt może być dużo łatwiejsze, naprawa lub zmiana ogranicza się do łatwych do identyfikacji fragmentów itp itd. Tylko nie wolno sobie pozwolić na drogę na skróty.

No tak, marketingowo to wszystko wspaniale wygląda, z praktyką gorzej. No i przede wszystkim, to minimalizacja kosztów oraz łatwniejsze wprowadzanie zmian jest celem całej inżynierii oprogramowania, i było nim na długo przed powstaniem DDD.
A DDD pełni głównie rolę buzzworda - firmy lubią się chwalić, że tak działają, niezależnie od tego, czy tak faktycznie jest (a zazwyczaj nie jest).

Wspomniane przez Ciebie "hexagonal architecture" wygląda mi na realizację tej samej idei.

Owszem. Tylko architektura to jedynie architektura, a DDD to jednak więcej - podejście do tworzenia oprogramowania, którego celem jest nie tylko architektura czy odpowiednie twory w kodzie, ale też np. rozwiązywanie problemów w komunikacji między biznesem a programistami.
Ogólnie nie ma żadnego problemu aby łączyć hexagonal z DDD, albo z czymś innym. Albo innej architektury z DDD.
Nie ma też problemu, żeby mieć czysty, łatwy do rozszerzania kod bez DDD. Wszystko zależy od stopnia skomplikowania procesów, którymi się zajmujemy. Niestety ludzie zamaist zastanowić się, czego tak naprawdę potrzebuja, często upierają się na buzwordy.

Jednak sama idea odwzorowywania rzeczywistych procesów jakoś do mnie przemawia.

Generalnie tym się zajmuje programowanie. Z DDD czy bez.

@somekind - mógłbyś podesłać jeszcze kilka haseł zbliżonych do tematu? coś jak to "hexagonal architecture", abym miał co czytać? temat fajny i ciekawy, a w drodze do pracy mam sporo czasu na czytanie :). Z góry dziękuję.

DDD sam znalazłeś, resztę podesłali koledzy powyżej. Nie wiem co jeszcze można dodać, chyba tylko praktykę.

0

I kolejny raz dziękuję wszystkim za pomocne informacje.
Coś czuję, że będę tutaj wracał aż Was zanudzę na śmierć :)

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