Mam takie pytanie czy wy też przed tym jakie jeszcze nic nie napisaliście to tworzycie sobie model konceptualny programu i bazy danych ja mam tak, że jest mi trudno wyobrazić sobie model programu dlatego tworzę najpierw model bazy danych, a jak już mam podstawowe pola to zaczynam pisać kod i potem przy pisaniu kodu wstawiam nowe pola do bazy danych czyli te na które nie wpadałem, a jak wy macie.
0
0
bazę tak lepiej zaprojektować wcześniej a potem dodawać braki. Nawet w zwykłym notatniku rozpisać tabele i pola to już wystarczy.
0
Lepiej na początku przemyśleć dobrze zarys architektury, niż potem w trakcie pisania dojść do wniosku, że właściwie trzeba wszystko robić od nowa.
1
Ja zazwyczaj najpierw modeluję obiektowo domenę (nawet rysując powiązania między obiektami na zwykłej kartce papieru), potem piszę kod. A potem ewentualnie generuję bazę danych.
No, ale ja w latach osiemdziesiątych się tylko urodziłem, więc nie projektuję aplikacji zaczynając od bazy danych, tak jak to się robiło w tamtych czasach.
0
Miałem różne etapy.
Najpierw pisałem na żywca. Dochodziłem często do etapu spaghetti kod.
Więc potem odbiłem w drugą stronę i zacząłem rysować wszystko na wielu kartkach, różnorakie diagramy, powiązania obiektów, próbowałem cały program zaprojektować. Zaczynałem kodować i w miarę kodowania uaktualniałem kolejne diagramy na kartkach. Tak żeby wszystko mieć pod kontrolą mentalną.
Jednak to nie zdało egzaminu, bo nie wiem jak dobrze bym zaprojektował to na kartce i w głowie, to ciągle się okazywało, że czegoś nie uwzględniłem w swoim pięknym projekcie. Więc i tak wychodził z tego spaghetti kod mimo pierwotnego designu.
Zacząłem więc akceptować to, że nie mogę zaprojektować od początku całej aplikacji, i zacząłem postrzegać tworzenie software'u bardziej w kategoriach kolejnych prób, kolejnych prototypów, przymiarek, eksperymentów, zbierania doświadczeń - a nie na zasadzie "jestem mądry i coś zaprojektuję" bo prawda jest taka, że nie da się zaprojektować aplikacji, jeśli się nie ma wystarczającego doświadczenia w danej działce programowania.
Więc teraz jak nie wiem jak do czegoś podejść to piszę szybko działający prototyp, żeby zobaczyć jak coś w praktyce działa, zobaczyć z jakimi problemami technicznymi się zetknę, w jaki sposób techniczny/czy od strony architektury/ można to rozwiązać, w jaki sposób lepiej tego nie rozwiązywać itp.
Potem po prototypie lub kilku prototypach, zaczynam pisać coraz bardziej świadomie, z celem. Tyle, że teraz projektuję bardziej w głowie niż na kartce.
1
somekind napisał(a):
...
No, ale ja w latach osiemdziesiątych się tylko urodziłem, więc nie projektuję aplikacji zaczynając od bazy danych, tak jak to się robiło w tamtych czasach.
Z opisu wynika, że właśnie dokładnie to robisz - tylko zmieniłeś nazwy Klasa >-< Encja. Pola >-< Relacje.
Jeżeli z modelu obiektowego da się wygenerować bazę danych - to ten model musi być strasznie ubogi.....
2
Najważniejsze są dane i relacje pomiędzy nimi. Kod to jest tylko otoczka która je odpowiednio interpretuje.
Tutaj fajny cytat Linusa Torvaldsa:
…git actually has a simple design, with stable and reasonably well-documented data structures. In fact, I'm a huge proponent of designing your code around the data, rather than the other way around, and I think it's one of the reasons git has been fairly successful […] I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
0
Dokładnie, też do mnie mocno trafił ten cytat i zawsze go sobie przypominam jak projektuję kod. To jedna z najlepszych porad na temat programowania, jakie znam.
Staram się pisać aplikacje w miarę możliwości data-driven, czyli mam jakieś dane na wejściu, i od tych danych zależy jak się program będzie zachowywał.
(chociaż nie wiem czy Linusowi chodziło o to dokładnie, czy raczej ogólnie o zwracanie uwagi na struktury danych).
W każdym razie wydaje mi się, że podejście data-driven ma masę zalet - choćby łatwa możliwość modyfikacji programu - zmieniamy tylko dane wejściowe i mamy inaczej zachowujący się program. Poza tym jeśli wszystko jest danymi, to łatwo zapisać stan aplikacji (robiąc jakąś serializację/save'a stanu), lepsze separation of concerns, bo te same dane można przekierować do różnych widoków etc.
Z drugiej strony widzę co się dzieje z projektami, które są robione odwrotnie - czyli struktury danych to tylko jakiś uzupełniacz w obiektówce - dużo projektów jest robionych na zasadzie "mamy obiekty, i najważniejsze są obiekty, metody, a jeśli będziemy potrzebować dane to po prostu stworzymy parę zmiennych prywatnych i jakieś gettery/settery, co ty chcesz, po co dane, ważniejsze jest OOP i nawrzucanie z 50 wzorców obiektowych, bo to jest profesjonalizm".
Tylko, że takie podejście kończy się zwykle tym, że projekt się rozrasta ponad miarę i rzeczy, które byłby proste w deklaratywnym podejściu data-driven, to przy podejściu imperatywnej zgniłej obiektówki po prostu często są niewykonalne bez poczynienia olbrzymich modyfikacji w projekcie i potworzeniu iluś klas i dziesiątek metod (tj. przy podejściu deklaratywnym łatwiej dodać nowy nieprzewidziany element, w podejściu zgniłego OOP ciężko to zrobić).
W sumie cieszę się, że od jakiegoś czasu podejście data-driven wraca do łask, przynajmniej we frontendzie (D3, React, Redux...).
1
@LukeJL to trochę nie tak. Wszystko jest dla ludzi. Po prostu niektórzy nauczyli sie jednej rzeczy i próbują tak robić wszędzie. A jak masz młotek to nagle wszystko przypomina gwoździe ;) Z twoim podejściem data-driven (które jest zresztą mocno zbliżone z programowaniem funkcyjnym) jest zresztą dokładnie tak samo. To nie żadne panaceum. Do jednej rzeczy się nada a do innej zupełnie nie. Sęk w tym żeby dobrze wybrać :)
Dla niektórych złożonych dziedzin wielokrotnie trudniej byłoby modelować program poprzez przepływ danych zamiast poprzez interakcje między obiektami biznesowymi.
0
Ale rozdzielenie procesów od struktur danych vs OOP, to jest zupełnie inny temat niż zaczynanie projektowania od bazy danych vs od kodu programu.
1
Szczerze? Nie wiem jak inaczej można by pisać stronę niż zaczynając od migracji i modeli bazodanowych czyli samej bazy. Następnie testy i lista metod a potem wypełnianie tych metod. Jak nie wiem jakie dane i gdzie się znajdują to skąd mam wiedzieć jak je przetwarzać?
1
mr_jaro napisał(a):
Szczerze? Nie wiem jak inaczej można by pisać stronę niż zaczynając od migracji i modeli bazodanowych czyli samej bazy. Następnie testy i lista metod a potem wypełnianie tych metod. Jak nie wiem jakie dane i gdzie się znajdują to skąd mam wiedzieć jak je przetwarzać?
A co jesli programujesz normalnie... i baza nie jest Ci do niczego potrzebna. Jest XXI wiek - bazy danych są czasami przydatne - ale z pewnością nie do składowania danych, bo to akurat robią wyjątkowo kiepsko.
See moje https://vimeo.com/170796157
albo Greg Young :
1
jarekr000000 napisał(a):
mr_jaro napisał(a):
Szczerze? Nie wiem jak inaczej można by pisać stronę niż zaczynając od migracji i modeli bazodanowych czyli samej bazy. Następnie testy i lista metod a potem wypełnianie tych metod. Jak nie wiem jakie dane i gdzie się znajdują to skąd mam wiedzieć jak je przetwarzać?
A co jesli programujesz normalnie... i baza nie jest Ci do niczego potrzebna. Jest XXI wiek - bazy danych są czasami przydatne - ale z pewnością nie do składowania danych, bo to akurat robią wyjątkowo kiepsko.
See moje https://vimeo.com/170796157
albo Greg Young :
Tworzę portale i aplikacje webowe. Tutaj bez bazy nic nie zdziałasz. Baza jest podstawą, bo odczytać i przetworzyć dane można na różne sposoby, ale trzeba je gdzieś mieć.
0
mr_jaro napisał(a):
Tworzę portale i aplikacje webowe. Tutaj bez bazy nic nie zdziałasz. Baza jest podstawą, bo odczytać i przetworzyć dane można na różne sposoby, ale trzeba je gdzieś mieć.
Wydaje Ci się, bo pewnie nie próbowałeś inaczej.
Polecam wideła.
Bo widziesz róznież zdarza mi się robić portale i aplikacje webowe :-) - i często mam tam baze danych - głównie wtedy jak mnie zmusi klient bzdurnymi standardami firmowymi. Ot taka kula u nogi. ... ale na szczęście nie zawsze mi się ktoś wtrąca - wtedy zależy: - w mega prostych aplikacjach czasem czegoś używam (np. jackrabbit- całkiem niezła javowa bazka do CMSów), w bardziej skomplikowanych ... raczej nigdy.
A dane owszem można przechowywać - ale przechowywanie danych w bazie danych to zwykle duże ograniczenie dla modelu (np. jak tam trzymasz funkcje?) - albo dla wydajności (dramat). Najczęściej jedno i drugie.
Bazy danych - jako perzystencja dla aplikacji- to taki cargo cult, który przetrwał do XXI wieku choć sens miał w latach 90 tych.
Przy okazji alternatywne podejście CQRS/ES , np., w postaci zabawkowej biblioteki, którą obisuje w wideo - też ma wady, ale jednak jest mniej upierdliwe i zdecydowanie bardziej elastyczne.
Przy okazji pod pojęciem bazy danych rozumiem - przechowywanie stanu aplikacji w jakimkolwiek enginie (SQL i NoSQL). W szczególności kiedy model do odczytu i zapisu jest ten sam. Bo przykładowa alternatywa to np. przechowywanie gdziekolwiek eventow (gdziekolwiek - choć tu ze względów technicznych często się używa Cassandry - nie przeszkadza tak bardzo) i tworzenie modeli tylko do odczytu (projekcji -np. w RAM).
Generalnie żeby podsumować:
modelowanie domeny systemu pod kątem perzystencji - czyli modelu w bazie danych uznaję za generalnie błąd- szybko się mści.
To co w tej chwili wchodzi do mainstream to modelowanie zdarzeń (i nawet takie wygłupy jak event storming). Reszta jest mało ważna - jeżeli zapisuje się tylko zdarzenia to sobie można stan systemu zawsze łatwo przegenerować i dopasować do nowych funkcji i potrzeb. W szczególności można mieć wiele równolegle pracujących baz danych, projekcji, widoków , które opisują stan systemu w zależności od potrzeb różnych modułów.
0
jarekr000000 napisał(a):
przechowywanie danych w bazie danych to zwykle duże ograniczenie dla modelu (np. jak tam trzymasz funkcje?)
Chyba wcale.
Generalnie, jeżeli naszą intencją jest przechowywanie dane, to nie możemy wymagać, aby nasze źródło przechowywało też zachowanie. (Jakkolwiek przechowywanie zachowywania definiować.)
albo dla wydajności (dramat).
O ile system jest na tyle duży, że wydajność bazy relacyjnej będzie dla niego problemem. Znaczna część systemów takiego problemu nie ma.
Przy okazji alternatywne podejście CQRS/ES
To też można trzymać w bazie danych. :)
modelowanie domeny systemu pod kątem perzystencji - czyli modelu w bazie danych uznaję za generalnie błąd- szybko się mści.
"Encja na twarz i pchasz" to akurat typowe podejście dużych firm i enterpriseowych technologii typu garbage collected XSLT (zwany potocznie JEE). Dzięki temu jest siedem warstw, repozytoria, serwisy, kontrolery - tyle wzorców, wszystko tak bardzo obiektowe, tylko nadal podstawą jest struktura danych bez logiki, za to z wyłącznie publicznymi polami. 1)
Tylko tak po prostu nie należy robić. Domena systemu i domena perzystencji, to dwie oddzielne domeny. Mało kto to rozumie, ale taka jest prawda. Tworząc (wystarczająco skomplikowany) system "porządnie", należy je obie zaprojektować oddzielnie. A nie system pod kątem składowania, co to w ogóle za osiemnastowieczne myślenie. ;)
W szczególności można mieć wiele równolegle pracujących baz danych, projekcji, widoków , które opisują stan systemu w zależności od potrzeb różnych modułów.
Ale... w bazie też można, nie?
- Żeby nie było - to nie jest zawsze złe. Transaction script operujący na strukturze może być zadowalającym i co ważne prostym rozwiązanie w przypadku wielu aplikacji, które nie mają zbytnio skomplikowanej logiki poza CRUDem. Tylko nie mówmy wtedy, że mamy DDD, bo mamy samozwańcze encje (np. dzięki jakiemuś atrybutowi czy klasie bazowej zwanej
Entity, albo dlatego, że tak się to nazywa w dokumentacji ORMa).
0
somekind napisał(a):
jarekr000000 napisał(a):
przechowywanie danych w bazie danych to zwykle duże ograniczenie dla modelu (np. jak tam trzymasz funkcje?)
Chyba wcale.
Generalnie, jeżeli naszą intencją jest przechowywanie dane, to nie możemy wymagać, aby nasze źródło przechowywało też zachowanie. (Jakkolwiek przechowywanie zachowywania definiować.)
-
Funkcja to rzecz,. Zachowanie to rzecz. Łatwo poznać bo odmienia się przez przypadki. (funkcji, z funkcją, Funkcjo! ,etc.)
-
Jakby Cie powyższa argumentacja nie przekonała to kolejny dowód:
To jest funkcja :
f-> x -> f (f (f ( f ( f ( f( x))))))
A tak naprawdę wiadomo, że to szóstka. I co teraz?
- Wracając do jednak tematów bardziej przyziemnych :
Załóżmy, że liczysz składki od pensji - i teraz w zależności od tego czy to umowa o pracę, o dzieło czy o coś tam jeszcze masz różne sposoby wyliczania np.
składki zdrowotnej.
Mógłbyś sobie wcisnąć do bazy enuma i potem wybierać switch casem, albo jakoś tam.
A możesz sobei w całej domenie przekazywać funkcję.... ( i wtedy jak Ci przyjdzie jakiś student z dziwną składką - to mu nawet ad hoc wrzucisz funkcje....).
W praktyce ze względu na pokazywanie na GUI - i tak jest jakaś hierarchia klas ( którą pewnie w 15 tabelek z pomocą ORM by się dało wcisnąć :-) ).