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

Odpowiedz Nowy wątek
2019-09-11 14:13
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źć.

Pozostało 580 znaków

2019-09-11 14:21
2

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


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-09-11 14:24
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.


Na każdy złożony problem istnieje rozwiązanie które jest proste, szybkie i błędne.

Pozostało 580 znaków

2019-09-11 14:45
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?

edytowany 4x, ostatnio: Yanno, 2019-09-11 14:47

Pozostało 580 znaków

2019-09-11 15:57
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?


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-09-11 18:31
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ę.

Pozostało 580 znaków

2019-09-13 12:21
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ć?

Pozostało 580 znaków

2019-09-23 16:08
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ł.

Pozostało 580 znaków

2019-09-23 16:21
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."

Pozostało 580 znaków

2019-09-23 16:27
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ń.

Pozostało 580 znaków

2019-09-23 20:19
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.

edytowany 2x, ostatnio: Yanno, 2019-09-24 10:51

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: CCBot (2x)