Temat: projektowanie a programowanie...

Jarek Żeliński:

Przepraszam, ale wcześniej tam nie zaglądałem: http://en.wikipedia.org/wiki/Multitier_architecture#Co...
Zgadzam się raczej z tym podejściem.

to typowe funkcyjne podejście, pytanie: dlaczego przytłaczająca ilość frameworków (w tym te zalecane przez wielu dostawców ERP, także Microsoft czy Oracle) to frameworki oparte na wzrocy MVC?

Nie rozumiem co jest w tym funkcyjnego. Nikt nie narzuca funkcyjnego podejścia do implementacji na warstwie aplikacji.

Nie proponuję wciskania bazy wszędzie gdzie się da. Aczkolwiek widziałem i takie rzeczy. Tam gdzie baza musi wystąpić i jest krytyczna dla systemu (duża niezawodność, integralność danych i czas wykonywania operacji) musi zostać zaimplementowana zgodnie ze sztuką. Tak więc chyba się zgadzamy, że różne systemy wymagają indywidualnego podejścia :)

mowa o bazie danych jako relacyjnym modelu danych czy o bazie danych w rozumieniu motor Oracle, Microsoft, czy IBM DB2?

Bo na tych motorach doskonale chodzą obiektowe, nierelacyjne systemy

Nie słyszałem, aby chodziły czysto obiektowe bazy danych z OQL. Chyba że coś się zmieniło. Obiektowo-relacyjne bazy są, mają się dobrze, ale nadal są obiektowo-relacyjne.

Temat: projektowanie a programowanie...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:45

Temat: projektowanie a programowanie...

Paweł Włodarski:

Aleksander Olszewski:

>

Z chęcią będę kontynuował dyskusję ale chciałbym abyśmy nie robili tego w formie 10 wątkowych spaghetti-postów :). Wybierz najciekawsza rzecz i odpisz w jednym takim tekstowym monolicie.

PS. Trzeba wrzucić trochę na luz. Moje ostatnie zdanie nie było niczym personalnym a jedynie niewinnym żarcikiem kontekstowym, także sorry jeśli inaczej to odebrałeś :)

Popieram to podejście ;) Proponuję na początek ten wątek: czy rzeczywiście dla obiektowego podejścia w projektowaniu i programowaniu nie ma miejsca na relacyjny model danych?

Znam kilka systemów, które jednak muszą mieć bazę danych pod sobą. Danych przybywa sporo, jest dużo użytkowników tych danych, liczy się też czas wykonywania zapytań. Czy w takiej sytuacji nadal nie warto sięgać po bazę?

Temat: projektowanie a programowanie...

Aleksander Olszewski:
Nie rozumiem co jest w tym funkcyjnego. Nikt nie narzuca funkcyjnego podejścia do implementacji na warstwie aplikacji.

oddzielenie danych od tego jak są przetwarzane do funkcyjne podejście znane z modeli DFD/ERD, jeżeli oddzielimy dane o od operacji na nich pozostają funkcje....

Bo na tych motorach doskonale chodzą obiektowe, nierelacyjne systemy

Nie słyszałem, aby chodziły czysto obiektowe bazy danych z OQL. Chyba że coś się zmieniło. Obiektowo-relacyjne bazy są, mają się dobrze, ale nadal są obiektowo-relacyjne.

serwer SQL jako implementacja repozytorium z prostym nierelacyjnym mapowaniem np. na bazie wzorca active records:
http://en.wikipedia.org/wiki/Active_record_pattern

użycie np. MS SQL nie implikuje że jest to relacyjny model danych....Jarek Żeliński edytował(a) ten post dnia 21.06.11 o godzinie 21:29

Temat: projektowanie a programowanie...

Aleksander Olszewski:
Popieram to podejście ;) Proponuję na początek ten wątek: czy rzeczywiście dla obiektowego podejścia w projektowaniu i programowaniu nie ma miejsca na relacyjny model danych?

i oddzielmy model relacyjny danych od narzędzia o nazwie "baza danych" bo to dwie odrębne rzeczy

Temat: projektowanie a programowanie...

Jarek Żeliński:
...
oddzielenie danych od tego jak są przetwarzane do funkcyjne podejście znane z modeli DFD/ERD, jeżeli oddzielimy dane o od operacji na nich pozostają funkcje....

Na pewno nie proponuje oddzielenia danych od operacji na nich. Wtedy zgodzę się z tym, że rzeczywiście przejdziemy na proceduralny styl programowania z pseudoobiektową otoczką :)

serwer SQL jako implementacja repozytorium z prostym nierelacyjnym mapowaniem np. na bazie wzorca active records:
http://en.wikipedia.org/wiki/Active_record_pattern

To co proponują pomysłodawcy architektury trójwarstwowej to pójście krok dalej. Chyba z grubsza zgodzimy się, że w przypadku ORM obiekty przejdą na encje. Jeśli tak, to dlaczego encje nie możemy połączyć relacją? Określić ogólne powiązania (typu jest w relacji), a wszystkie ewentualne ograniczenia biznesowe (typu jeśli faktura opiewa na kwotę większą niż 1000 PLN) rozwiązać na poziomie klas?

Wydaje mi się, że jest to esencja naszej dyskusji :)

Temat: projektowanie a programowanie...

Ja ze swojej strony pragnąłbym zauważyć, że wzorzec Active Record nie jest najlepszym przykładem rozdzielenia db o struktury klas, jest zbyt bardzo jest przywiązany do bazy danych. Dużo lepszym rozwiązaniem jest wzorzec Data Mapper. Co do samych baz, nie można być zapatrzonym tylko w bazy relacyjne. Zwróciliście uwagę na bazy obiektowe, natomiast nie są one zbyt popularne, za to na znaczeniu zyskują bardzo bazy dokumentowe (CouchDb, MongoDb, Cassandra), które moim zdaniem lepiej nadają się do utrwalania obiektów niż bazy relacyjne.

Temat: projektowanie a programowanie...

Aleksander Olszewski:

Jarek Żeliński:
...
oddzielenie danych od tego jak są przetwarzane do funkcyjne podejście znane z modeli DFD/ERD, jeżeli oddzielimy dane o od operacji na nich pozostają funkcje....

Na pewno nie proponuje oddzielenia danych od operacji na nich.

to dlaczego dane są w bazie a algorytmy (funkcje) osobno w kodzie aplikacji?

serwer SQL jako implementacja repozytorium z prostym nierelacyjnym mapowaniem np. na bazie wzorca active records:
http://en.wikipedia.org/wiki/Active_record_pattern

To co proponują pomysłodawcy architektury trójwarstwowej to pójście krok dalej.

co znaczy "o krok dalej"?

Chyba z grubsza zgodzimy się, że w przypadku ORM obiekty przejdą na encje.

ORM to implementacja czyli "jak obsłużyć zapamiętywanie stanów obiektów z pomocą bazy relacyjnej", ORM nie ma nic (bezpośrednio) wspólnego z obiektowością, to tylko MAPOWANIE... po drugie ORM stosowane jest TYLKO gdy baza relacyjna istnieje i MUSIMY z niej korzystać, projekty obiektowe "od zera" omijają model relacyjny "szerokim łukiem"...

Jeśli tak, to dlaczego encje nie możemy połączyć relacją?

encje są w bazach relacyjnych i można je łączyć jak się chce :), obiekty się komunikują z pomocą komunikatów, których argumentami mogą (bo nie muszą być) dane...a to ogromna różnica.

zadam pytanie: jak i jaką relacją oraz w jakiej bazie mam połączyć klienta w moim systemie CRM (używanym go jako SaaS) z drugim moim systemem zdalnych wydruków na innym systemie SaaS, pracują razem dokoskonalne, listy wychodzą a nie ma tu żadnych "relacji a bazie łączących klienta z listem jaki do niego wysyła", mój CRM wysyła do Drukarni komunikat "wydruku list" gdzie parametrami polecenia jest treść listu i nazwa (albo NIP) klienta ale są to zupełnie rozłączne systemy (żadnych danych nie współdzielą).

Określić ogólne powiązania (typu jest w relacji), a wszystkie ewentualne ograniczenia biznesowe (typu jeśli faktura opiewa na kwotę większą niż 1000 PLN) rozwiązać na poziomie klas?

a czym tu jest więc klasa?

Wydaje mi się, że jest to esencja naszej dyskusji :)

tak: mieszanie systemów projektowanych obiektowych z systemami projektowanymi strukturalnie.

Nie widzę nic złego w strukturalnym podejściu do projektowania i programowania widzę tylko różnicę między nimi :)

Temat: projektowanie a programowanie...

na rozluźnienie:

Temat: projektowanie a programowanie...

Jarek Żeliński:

Aleksander Olszewski:

...

...

to dlaczego dane są w bazie a algorytmy (funkcje) osobno w kodzie aplikacji?

ok, mamy same obiekty, ale jeśli wyłączymy aplikację, obiekty muszą gdzieś swoje stany zapisać, czasami na dysku, czasami w bazie. Chciałbym, aby był to dysk, ale niestety wybór często pada na bazę.

To co proponują pomysłodawcy architektury trójwarstwowej to pójście krok dalej.

co znaczy "o krok dalej"?

Proponuję taką budowę systemów, aby warstwa danych, aplikacji i prezentacji była w "każdym momencie" wymienialna. Jest to rodzaj paradygmatu.

Jeśli tak, to dlaczego encje nie możemy połączyć relacją?

encje są w bazach relacyjnych i można je łączyć jak się chce :), obiekty się komunikują z pomocą komunikatów, których argumentami mogą (bo nie muszą być) dane...a to ogromna różnica.

zadam pytanie: jak i jaką relacją oraz w jakiej bazie mam połączyć klienta w moim systemie CRM (używanym go jako SaaS) z drugim moim systemem zdalnych wydruków na innym systemie SaaS, pracują razem dokoskonalne, listy wychodzą a nie ma tu żadnych "relacji a bazie łączących klienta z listem jaki do niego wysyła", mój CRM wysyła do Drukarni komunikat "wydruku list" gdzie parametrami polecenia jest treść listu i nazwa (albo NIP) klienta ale są to zupełnie rozłączne systemy (żadnych danych nie współdzielą).

Zgadzam się z tym w 100% :) Nie musimy łączyć wszystkiego ze wszystkim na poziomie bazy. W architekturze rozproszonej (z ewentualnymi ośrodkami odpowiedzialności) komunikacja pomiędzy komponentami zachodzi na poziomie interfejsów.

Wydaje mi się, że jest to esencja naszej dyskusji :)

tak: mieszanie systemów projektowanych obiektowych z systemami projektowanymi strukturalnie.

Nie mieszam systemów. Niestety nadal występują heterogeniczne systemy i występować będą. Wszystkiego niestety nie przepiszemy. Architektura trójwarstwowa (potencjalnie wielowarstwowa) jest podejściem, jak zorganizować to co musimy zrobić i rozbić to na warstwy.

Nie widzę nic złego w strukturalnym podejściu do projektowania i programowania widzę tylko różnicę między nimi :)

Też widzę różnice między jednym i drugim. Wolałbym też, aby wreszcie pojawiły się normalne bazy obiektowe, a nie protezy obiektowe na relacyjnym modelu.

Temat: projektowanie a programowanie...

Wojciech Soczyński:
Ja ze swojej strony pragnąłbym zauważyć, że wzorzec Active Record nie jest najlepszym przykładem rozdzielenia db o struktury klas, jest zbyt bardzo jest przywiązany do bazy danych. Dużo lepszym rozwiązaniem jest wzorzec Data Mapper.

to prawda, posłużyłem się jedynie pierwszym z brzegu przykładem ale masz racje, nie najlepszym :), jednak wzorzec Active Records jest bardzo często stosowany:
http://social.msdn.microsoft.com/Search/en-US?query=ac...

o ile wiem stosowany jest w Dynamix AX, ale w innych ERP także,...

Co do samych baz, nie można być zapatrzonym tylko w bazy relacyjne. Zwróciliście uwagę na bazy obiektowe, natomiast nie są one zbyt popularne, za to na znaczeniu zyskują bardzo bazy dokumentowe (CouchDb, MongoDb, Cassandra), które moim zdaniem lepiej nadają się do utrwalania obiektów niż bazy relacyjne.

Obserwują rynek narzędzi idzie to chyba w kierunku dostarczania gotowych implementacji wzorca "Repozytorium"....

Temat: projektowanie a programowanie...

Aleksander Olszewski:
ok, mamy same obiekty, ale jeśli wyłączymy aplikację, obiekty muszą gdzieś swoje stany zapisać, czasami na dysku, czasami w bazie. Chciałbym, aby był to dysk, ale niestety wybór często pada na bazę.

to implementacja "utrwalania" a nie logika biznesowa... można to zrobić (zapamiętać stany obiektów) na wiele sposobów...

To co proponują pomysłodawcy architektury trójwarstwowej to pójście krok dalej.

co znaczy "o krok dalej"?

Proponuję taką budowę systemów, aby warstwa danych, aplikacji i prezentacji była w "każdym momencie" wymienialna. Jest to rodzaj paradygmatu.

jak wymienić warstwę aplikacji oddzielając ją od danych????? będzie "samowystarczalna??????

Jeśli tak, to dlaczego encje nie możemy połączyć relacją?

encje są w bazach relacyjnych i można je łączyć jak się chce :), obiekty się komunikują z pomocą komunikatów, których argumentami mogą (bo nie muszą być) dane...a to ogromna różnica.

zadam pytanie: jak i jaką relacją oraz w jakiej bazie mam połączyć klienta w moim systemie CRM (używanym go jako SaaS) z drugim moim systemem zdalnych wydruków na innym systemie SaaS, pracują razem dokoskonalne, listy wychodzą a nie ma tu żadnych "relacji a bazie łączących klienta z listem jaki do niego wysyła", mój CRM wysyła do Drukarni komunikat "wydruku list" gdzie parametrami polecenia jest treść listu i nazwa (albo NIP) klienta ale są to zupełnie rozłączne systemy (żadnych danych nie współdzielą).

Zgadzam się z tym w 100% :) Nie musimy łączyć wszystkiego ze wszystkim na poziomie bazy. W architekturze rozproszonej (z ewentualnymi ośrodkami odpowiedzialności) komunikacja pomiędzy komponentami zachodzi na poziomie interfejsów.

Uffff :)

Nie mieszam systemów. Niestety nadal występują heterogeniczne systemy i występować będą. Wszystkiego niestety nie przepiszemy.

no... nowe systemu zastępują stare.... te wartościowe (nadal przydatne) są przepisywane, faktem jest, że to kosztowne...

Nie widzę nic złego w strukturalnym podejściu do projektowania i programowania widzę tylko różnicę między nimi :)

Też widzę różnice między jednym i drugim. Wolałbym też, aby wreszcie pojawiły się normalne bazy obiektowe, a nie protezy obiektowe na relacyjnym modelu.

osobiście straciłem wiarę w "bazy obiektowe", widzę zaś postęp w gotowych implementacjach "repozytoriów" i to mi sie bardziej podoba bo to gotowe komponenty... mnie nie interesuje implementacja utrwalania, mnie interesuje coś co ma interfejs, który "zeżre" moje setki faktur lub spotkań na najbliższy rok, zapamięta i odda jak poproszę. Jak to repozytorium będzie "stworzone" to problem "programistów" (implementacja), dlatego forsuje w projektach rozdzielnia projektowania od programowania co w paradygmacie obiektowym jest proste... w strukturalnym w zasadzie nie możliwe...

Temat: projektowanie a programowanie...

Jarek Żeliński:
...
jak wymienić warstwę aplikacji oddzielając ją od danych????? będzie "samowystarczalna??????

Niestety nie. Z resztą nie takie jest założenie tego podejścia. Mówi jedynie tyle, ze "utrwalanie" powinno być wymienne.

Wydaje mi się, że cenimy podobne wartości w projektowaniu, jednakże z innych stron na nie spoglądamy :)

Temat: projektowanie a programowanie...

Aleksander Olszewski:

Jarek Żeliński:
...
jak wymienić warstwę aplikacji oddzielając ją od danych????? będzie "samowystarczalna??????

Niestety nie. Z resztą nie takie jest założenie tego podejścia. Mówi jedynie tyle, ze "utrwalanie" powinno być wymienne.

oczywiście, repozytorium dowolne byle było,

dla mnie priorytetem w projektach jest możliwość odzienia od siebie (a nawet wręcz rezygnacja) z dowolnego komponentu (modułu) i wymiana na inny lepszy, a tego nie da się w zintegrowanym systemie postawionym na znormalizowanej bazie (czytaj model danych). Taki wielki np. ERP (albo cokolwiek innego) nie da się "pociąć" by integrować jako usługę SaaS, Cloud czy cokolwiek podobnego... są systemy z gruntu niepodzielne (np. PESEL) i tu model relacyjny składowania tych danych jest chyba najlepszy, ale w systemach biznesowych, gdzie warunki (czytaj wymagania) zmieniają się jak w kalejdoskopie nie widze sensu (i praktyka to potwierdza) takiego "zamrożenia".

Wydaje mi się, że cenimy podobne wartości w projektowaniu, jednakże z innych stron na nie spoglądamy :)

zapewne :)

Temat: projektowanie a programowanie...

Czyli prosta recepta - buduj software z modułów, które udostępniają mocno abstrakcyjne API, natomiast implementuj ichszczegóły w tym co najlepiej pasuje do danego zagadnienia ;)Wojciech Soczyński edytował(a) ten post dnia 22.06.11 o godzinie 11:05

Temat: projektowanie a programowanie...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:48

Temat: projektowanie a programowanie...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:48

Temat: projektowanie a programowanie...

Paweł Włodarski:
...
Ok, przyznam się ,że to ja nie wyraziłem się dosyć szczegółowo :) Wybierz najciekawszą rzecz z NASZEJ dyskusji:)

W takim razie rzeczywiście źle zrozumiałem. Odniosłem się w pewnym stopniu do sedna dyskusji ogólnej. Nie odniosłem się do twojej odpowiedzi. Obawiam się, że jeśli zaczniemy grać w pingponga zabijemy cały wątek. A chyba nie o to chodzi.

Ale skoro już pytasz to tez znam systemy przechowujące Dane w "bazach danych", użytkownicy są szczęśliwi a nowe funkcjonalności można wprowadzać relatywnie łatwo. Właściwa odpowiedź może brzmieć "ZALEŻY" a w swoim pytaniu zawarłeś kryteria, które mogą "zależy" przepchnąć w jedną lub drugą stronę.

Osobiście zaś z zainteresowaniem przyglądam się w kierunku http://en.wikipedia.org/wiki/NoSQL.

Tu też napiszę "ZALEŻY". Całą koncepcja NoSQL (not only SQL) nie porzuca samego SQL, a rozbudowuje go i próbuje zrobić bardzie elastycznym. Założę się, że każdy programista (Inżynier) robił to i przed tym, tyle że bez "kolorowej nalepki". Nikt przecież nie zabrania przechowywać zserializowane dane. Problem jest w tym, że zrobić to można na wiele sposobów. Programista często wybiera sposób dla siebie bliższy ze względu na język. Projektant raczej powinien zaproponować coś bardziej ogólnego bliższego standardom (JSON, XML, itd.). Nie chcę tu wchodzić w szczegóły implementacyjne.

Dodam jeszcze jedną ciekawostkę dla zwolenników NoSQL. Otóż NoSQL (przypominam, że nie jest zaprzeczeniem SQL, a jego rozszerzeniem lub wariacją) opiera się na twierdzeniu CAP. Konsekwencją tego twierdzenia jest to, że mamy do wyboru CA, CP lub AP. Oto ciekawostka: dwie z tych trzech kombinacji zakładają, że jednak integralność danych ma być zachowana.

Próbą pogodzenia tych trzech kombinacji trzech literek jest architektura BASE (Basically Available, Soft-state, Eventually consistent). Zakłada ona kilka rzeczy. Jedna z nich to to, że zachodzi uzgodnienie danych na końcu serii akcji, lub raz na jakiś czas.

Temat: projektowanie a programowanie...

Paweł Włodarski:
...
No i teraz ta kwestia z projektantem i programistą. Gdy tworzysz test i opisujesz w nim co dokładnie ma się stać w logice (zanim w ogóle powstaną klasy) (TDD), następnie implementujesz właściwą logikę to gdy ów test będzie faktycznie jednostkowy to zauważysz, że musisz trzymać się kilku poprawnych praktyk w obszarach takich jak :Loose_coupling czy Cohesion
i wiele innych dobrych rzeczy.

Teraz nazwijmy po imieniu co się stało: programując test zaprojektowałeś jego rozwiązanie uwzględniające wiele dobrych praktyk z zakresu tworzenia rozwiązań informatycznych , programując test zaprojektowałeś dobre rozwiązanie , PROGRAMUJĄC... ZAPROJEKTOWAŁEŚ..., albo jesteś projektantem, który dobrze programuje albo programista, który dobrze projektuje, jesteś projektanto-programistą , programisto-projektantem , lub w skrócie Inżynierem. Jednakże twój model tego może nie przełknąć ;)

Nie chcę się czepiać słów, ale jeśli Inżynier pójdzie parzyć kawę, to staje się ..? Proszę potraktować to jako żart :) Inżynier ma wiele umiejętności i wiedzy --- temu nie przeczę. Co niektórzy są w stanie przełączyć się pomiędzy rolami projektowymi błyskawicznie, inni nie. Żeby uniknąć tego rodzaju problemów, trzeba zwyczajnie te role fizycznie rozdzielić pomiędzy osoby.

Dlaczego zacząłem mówić o TDD? Zgodnie z V-Modelem (przepraszam, że odszedłem od Wikipedii, ale tam opis jest znacząco niewystarczający) przynajmniej wstępny projekt testów jednostkowych powinien powstać tuż przed implementacją. Niestety nie mogę chwilowo znaleźć bardziej rozbudowanego modelu testów. Wedle niego mamy również testy czarnej i białej skrzynki. Zgodnie z TDD najpierw piszemy testy jednostkowe, a dopiero później implementujemy.

Problem z testami jednostkowymi jest taki, że dużo osób przywiązuje uwagę na ilościowe pokrycie testami a nie jakościowe. Dlaczego często odchodzi się od testów białej czarnej skrzynki? Otóż jeśli w testach jednostkowych uwzględnimy wszystkie punkty decyzyjne oraz klasy parametrów wejściowych dostaniem 3 w 1. I to będzie to, co widać na załączonym obrazku.

Pytanie jest właściwie takie: łatwo możemy wprowadzić metrykę ilościową pokrycia testami kodu. Czy da się wprowadzić metrykę jakościową? Kto ma odpowiadać za klasy parametrów? Czy ktoś powinien weryfikować przejścia przez punkty decyzyjne? Czy to ma być programista czy projektant? Może osobna rola w projekcie?

Także jeśli po prostu dostarczasz ludziom przy klawiaturach gotowe metody i mówisz "wypełnijcie to kodem" to możemy co najwyżej mówić o pisaniu testów nie o zaś TDD.

Na koniec, na rozluźnienie atmosfery przytoczę żart:
Kiedy skończy się informatyka?
Gdy skończą się skróty 3 literowe.
Stąd powstały skróty 4 literowe.Aleksander Olszewski edytował(a) ten post dnia 23.06.11 o godzinie 14:15

Temat: projektowanie a programowanie...

.Ten post został edytowany przez Autora dnia 05.08.16 o godzinie 20:48