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
1

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
1

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
0
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

Odpowiedz
Liczba odpowiedzi na stronę

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