konto usunięte

Temat: We are not OOP programmers anymore

Rafał G.:
Paweł,

"(...)I ostatnio był ten co to opracował to SOLID (nie akronim tylko zasady) - niejaki Robert C. Martin(...)"

napisałeś, że Uncle Bob Martin opracował SOLID. A co z L-iskov Substitution Principle ?

No będę strzelał, że w jego opracowaniu znajduje się to pod literą L - chociaż o tej godzinie niczego nie można być pewnym.

Mogę również jedynie zgadywać iż chodziło ci o to, że nie wymyślił - no nie wymyślił dlatego nazywa się to Liskov a nie Martin Substitution Principle - no chyba, że darzył ją uczuciem i postanowił owe principium przyozdobić jej nazwiskiem (choć imię byłoby bardziej romantyczne). Sądzę, iż takie przypadki zdarzały się nie raz gdy pewien zbłąkany podróżnik nazywał miasta,rzeki czy doliny imionami swoich miłości.

Tutaj jednak chyba tak się nie stało gdyż z tego co mi wiadomo - niejaka Barbara Liskov przedstawiła pewne koncepcje (oj trzeba uważać na słowa bo łowcy wątków czekają) które to koncepcje później Robert C Martin wykorzystał w swoim opracowaniu

I tutaj Istotne jestj słowo "opracować" - które ma następujące synonimy - "obrobić, omówić, zredagować"

Wydaje mi się, że użyłem tego słowa poprawnie w zacytowanym przez cię zdaniu i moja polonistka z technikum byłaby naprawdę ze mnie dumna. Pozostaje pytanie o dziwny komentarz w nawiasie odnośnie akronimu - który gramatycznie może odstawać od reszty zdania (komentarz - nie akronim). Otóż na podstawie pewnego doświadczenia w dyskusjach na goldenline zauważyłem, że czasami ludzie lubią uczepić się jednego zdania i rozpocząć nie do końca produktywny wątek dyskusji. Toteż pomyślałem sobie, że może umieszczę małe zabezpieczenie jakby ktoś chciał się kłócić, że to nie on wymyślił ów skrót (bo z tego co mi wiadomo to ktoś inny wymyślił ów skrót) - jak widać odniosłem jedynie częściowy sukces (lub jak kto woli częściową porażkę - chociaż podobno lepiej być optymistą bo wtedy układ immunologiczny lepiej działa - podobno)

pzdr
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: We are not OOP programmers anymore

Jakub W.:
Jarosław Ż.:
Dlaczego "brak obiektowości" jest problemem w przypadku rozbudowanej logiki biznesowej ? :)

bo jeżeli się złożonego problemu nie podzieli na mniejsze to znacznie trudniej nim zarządzać,

tylko dlaczego "brak obiektowości" (a jeśli rozumiem intencje twórcy wątku - brak DDD) ma oznaczać problem ?

mogę się jedynie domyślać, że "brak obiektywności" to brak panowania nad złożonością projektu zaś "brak DDD" to brak komunikacji z klientem

Anemiczny model domeny oznacza tylko tyle, że "logika jest oddzielona od stanu" i nie uważam, żeby to był jakiś "straszny błąd" ponieważ sam, przez ok 2 lata, developowałem duży system oparty właśnie na tej zasadzie i nie miałem z tym żadnego problemu.

problem polega na tym, (zapewne nie zawsze) że oddzielenie tego "co zrobić" od tego "z czym to zrobić", to tak jak być oddzielił ludzi od ich umiejętności. Innymi słowy: mając np. dużą brygadę budowlaną masz dwa wyjścia:
1. mieć osobno: kupę narzędzi, kupę materiałów i liczba grupę ludzi o prostych (atomowych) umiejętnościach, i rzucić się na to wszystko by doprowadzić do powstania wieżowca
2. mieć dobre umowy o dzieło i zlecenie podpisane ze stosowną liczbą podwykonawców, mieć projekt całości i zarządzać jedynie zlecanymi zadaniami.

każdy sam wybiera metodę prowadzenia wielkich budów

Jakakolwiek architektura ma tylko jeden cel - ma być skuteczna; niekoniecznie elegancka.

jak definiujesz elegancję?

"systemy nie są obiektowe - w domyśle DDD"

powyższe jest nieprawdą, po drugie sugeruje rozróżnianie pojęcia "obiektowy = kod podzielony na klasy" od "obiektowy = zamodelowany/zaprojektowany jako współpracujące obiekty"

mało która firma potrafi zaplanować rozwój systemu IT.

dlatego tylko niektóre osiągają sukcesy

Obecnie 95% (opracowanie własne) software'u robi się "na pałę"

potwierdzam,
(niektórzy wolą określenie -Agile-) co w skrócie oznacza "nie wiemy co, nie wiemy jak, ale jesteśmy zmotywowani więc zrealizujemy projekt". Efekt chyba jest znany.

:)
Najzabawniejsze jest to, że te różne firmy próbują właściwie wszystkiego, żeby robić dobry soft: zmieniają organizację pracy (Agile), organizację kodu (DDD), metody testowania, sposoby motywowania itd .. tylko jakoś nikomu z nie przychodzi do głowy, że właściwie nie wie co (nie wspominając o jak) ostatecznie trzeba zrobić.
to troszkę jak w wojsku: na dowolnym poziomie oficer ma ok. 7 podwładnych z którymi się komunikuje, wyobraź sobie generała który ma wydawać polecenia bezpośrednio to kilkunastu tysięcy żołnierzy a ci konsultują wszystko między sobą , zresztą tak wygląda wiele programów które widywałem ;)

"Proof by analogy is fraud." :)

to prawda, ale to nie dowód a metafora :)

... ciekawe czy ktoś / kiedyś sprzeda wojsku "Agile / Scrum" ;)

nie sądzę, nikt nie zgodzi się na taką liczbę ofiar :), ale historia zna wojny Agile: np. Stalin nie uznawał pojęcia "ograniczone zasoby"... miał największe straty w ludziach i koszty w II wojnie światowej (w ZSRR zwanej Wielką Wojną Ojczyźnianą), Obecne projekty Agile zaliczane do sukcesów (miarą sukcesu jest wyłącznie doprowadzenie projektu do zakładanego końca) z reguły mają potężnie przekroczone budżety albo, gdy sukcesem jest spożytkowanie 100% budżetu, funkcjonalność zbyt małą by produkt był użyteczny (projekty zarzucone)

Yhm - ale to wskazuje, że "problem" polega na tym, że firmy biorące się za realizację złożonych projektów _czasami_ nie wiedzą jak to (realizować) robić.

bo to częste zjawisko :)

so true... szkoda tylko, że to samo (tzn. często nie wiedzą jak wybrać dobrego wykonawcę) dotyczy klientów tych firm :\

stawiam tezę, że 3/4 problemow klienci maj a na własne życzenie, jednak "nie do końca", bo klient - w przeciwieństwie do usługodawcy - ma prawo nie znać się na inżynierii oprogramowania, szkoda że bardzo często nie zna się także na zarządzaniu :(
.

konto usunięte

Temat: We are not OOP programmers anymore

Paweł,

Są sytuacje kiedy wracając po spotkaniu ze znajomymi, wieczorem do domu należałoby się już tylko położyć spać. Obawiam się, że wczoraj zdobyłem kolejny dowód na to, że tak właśnie jest :)

Sorry za głupi offtop.

konto usunięte

Temat: We are not OOP programmers anymore

"Plan jest niczym, planowanie jest wszystkim"

Nie wyobrażam sobie pisania na pałę. Nie mówię, że bez planu nic nie powstanie, pytanie tylko co. Niestety większość firm nie kładzie nacisku na planowanie, liczy się aby coś powstało, jakieś zajefajne gui najlepiej web 4.0+ . Przecież nikt nie mówi, że w czasie gdy powstają plany nie można tworzyć jakiejś bazy. Przecież można użyć resta i gui robić całkowicie odrębnie.

Problem polega na tym, że bez planu i obiektowego podejścia, zazwyczaj okazuje się, że powstało 10 różnych klas z utilsami, brak luźnego wiązania, przerost formy nad treścią , kochane serwisy tzw. Ośmiotysięczniki (moje ulubione), gdzie tylko ten kto je pisał tak naprawde wie o co w tym biega, brak jakiejkolwiek dokumentacji, nawet tego głupiego javadoc, testy -- a co to jest przecież bez tego działa.

Są też dobre strony. Oprogramowanie powstało w 4 miesiące nie w 7 . Nie potrzeba było mieć zbytnio doświadczonych ludzi, koszty małe, jakoś to tam działa, no po prostu szefostwo zadowolone w pełni.

Następnie po roku albo wcześniej okazuje się, że pasuje projekt rozszeżyć, albo ruch jest większy i pasuje żeby było szybciej , lepiej się skalowało i perfomance 100 %. Szefostwo wychodzi z założenia, że skoro cały projekt udało się napisać w 4 miesiące to takie tam dołożenie kilku modułów, czy refraktoryzacja potrwa pewnie góra 2.

Co się dzieje w rzeczywistości. Niektórzy się domyślają. Część ekipy się zmieniła, patrzą na ten kod i O_o wielkie bubu :D . Dokumentacji ni w ząb, żadnego modelu, co gdzie i jak, kochane ośmiotysięczniki, brak testów to jak do cholery poprawiać, itd itd. To są minusy. Nie chcę powiedzieć, i nie twierdzę, że tylko podejście DDD i obiektowość się sprawdze we wszystkich przypadkach. Jednak każdy projekt powinien być planowany, pytanie tylko w jakim stopniu.....
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: We are not OOP programmers anymore

Łukasz W.:
Następnie po roku albo wcześniej okazuje się, że pasuje projekt rozszeżyć, albo ruch jest większy i pasuje żeby było szybciej , lepiej się skalowało i perfomance 100 %. Szefostwo wychodzi z założenia, że skoro cały projekt udało się napisać w 4 miesiące to takie tam dołożenie kilku modułów, czy refraktoryzacja potrwa pewnie góra 2.

dlatego ja wymagam od developera podania w ofercie:
- kosztów i terminu wytworzenia konkretnej (zakres projektu) puli funkcjoności
- kosztu każdej przyszłej kolejnej nowej funkcjonalności (z podzialem na CRUD, standard i złożone)
- nie dopuszczam projektów T&M

jak ktoś nie potrafi to mu dziękuję, to prosty miernik jakości projektowania.
X X

X X Software Engineer

Temat: We are not OOP programmers anymore

Chciałbym zapytać Panów narzekających na dzisiejsze podejście przy projektowaniu oprogramowania - Czy uważacie, że Agile jako taki jest zły, czy też jego wypaczona wersja będąca wymówką dla braku jakichkolwiek planów jest zła?
Jarosław Szczepankiewicz

Jarosław Szczepankiewicz Lead Technical
Consultant

Temat: We are not OOP programmers anymore

Jarosław Ż.:
- kosztu każdej przyszłej kolejnej nowej funkcjonalności (z podzialem na CRUD, standard i złożone)

hmm, możesz wyjaśnić co przez to rozumiesz? bo mnie aż swędzi żeby się dowiedzieć w jaki sposób określasz "każdą przyszłą nową funkcjonalność"? i jak to można oszacować?
jak ktoś nie potrafi to mu dziękuję, to prosty miernik jakości projektowania.

konto usunięte

Temat: We are not OOP programmers anymore

Konrad B.:
Chciałbym zapytać Panów narzekających na dzisiejsze podejście przy projektowaniu oprogramowania - Czy uważacie, że Agile jako taki jest zły, czy też jego wypaczona wersja będąca wymówką dla braku jakichkolwiek planów jest zła?

A jakie jest zdanie na ten temat specjalistów agile ?
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: We are not OOP programmers anymore

Jarosław S.:
Jarosław Ż.:
- kosztu każdej przyszłej kolejnej nowej funkcjonalności (z podzialem na CRUD, standard i złożone)

hmm, możesz wyjaśnić co przez to rozumiesz? bo mnie aż swędzi żeby się dowiedzieć w jaki sposób określasz "każdą przyszłą nową funkcjonalność"? i jak to można oszacować?
jak ktoś nie potrafi to mu dziękuję, to prosty miernik jakości projektowania.

można trak zaprojektować architekturę, że kolejny "use case" będzie kolejnym "liniowo" przyrostowym zestawem klocków, "przeciętna" liczba klas na use case jest dość podobna, systemy biznesowe nie mają logiki w rodzaju "rozpoznawanie tekstu OCR. Te trzy "wagi' ciężkości z reguły pozwalają pogrupować usługi systemu na porównywalne kosztowo. Nie wiem co mam Ci tu napisać, poza tym, ze postawienie całości na jednej bazie w modelu relacyjnym nie pozwala na taka ofertę.

konto usunięte

Temat: We are not OOP programmers anymore

Jarosław Ż.:
Jakub W.:
Jarosław Ż.:
>
Anemiczny model domeny oznacza tylko tyle, że "logika jest oddzielona od stanu" i nie uważam, żeby to był jakiś "straszny błąd" ponieważ sam, przez ok 2 lata, developowałem duży system oparty właśnie na tej zasadzie i nie miałem z tym żadnego problemu.

problem polega na tym, (zapewne nie zawsze) że oddzielenie tego "co zrobić" od tego "z czym to zrobić", to tak jak być oddzielił ludzi od ich umiejętności.

Wciąż nie widzę problem (zwłaszcza, że go nie było) :)
Nie twierdzę, że AMD jest "lepszy" od "DDD". Chciałem jedynie zaznaczyć, że potencjalny brak DDD samo z siebie nie jest problem... no chyba że kogoś interesuje bardziej ideologia niż robienie czegoś co działa.
Jakakolwiek architektura ma tylko jeden cel - ma być skuteczna; niekoniecznie elegancka.

jak definiujesz elegancję?

Eleganckie rozwiązania to takie, które radzą sobie z "problemami" dzięki jakości i dobrej organizacji kodu, a nie jego ilością. :) Tak w skrócie...Ten post został edytowany przez Autora dnia 27.09.13 o godzinie 15:41
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: We are not OOP programmers anymore

Jakub W.:
Nie twierdzę, że AMD jest "lepszy" od "DDD". Chciałem jedynie zaznaczyć, że potencjalny brak DDD samo z siebie nie jest problem... no chyba że kogoś interesuje bardziej ideologia niż robienie czegoś co działa.

AMD do DDD ma się jak pieść do nosa, AMD to javascript czyli głownie (tylko) GUI a DDD to zestaw wzorców dla Modelu Dziedziny (w MVC) czyli na pewno nie GUI.

Stosowanie DDD to nie religia, a jak dotąd jedyny wzorzec (poza prostszym starym BCE), operujący na zestawie biznesowych pojęć dlatego pozwala na analizę opracowanie modelu dziedziny wiernie odwzorowującego "biznes" i tym samym zrozumiały (weryfikowalny) przez biznes.

Owszem, można uznać, że model dziedziny to nie biznesu broszka, ale wtedy developer tworzy model nie mając pojęcia czy jest dobry, a że jako developer nie jest "biznesem" więc często tworzy niedobre modele dziedziny i mamy to co mamy: 75% projektów to wtopy.


Jakakolwiek architektura ma tylko jeden cel - ma być skuteczna; niekoniecznie elegancka.

jak definiujesz elegancję?

Eleganckie rozwiązania to takie, które radzą sobie z "problemami" dzięki jakości i dobrej organizacji, a nie jego ilością. :) Tak w skrócie...

no to ja jestem jednak za elegancją :) w architekturze
Jarosław Szczepankiewicz

Jarosław Szczepankiewicz Lead Technical
Consultant

Temat: We are not OOP programmers anymore

Jarosław Ż.:
AMD do DDD ma się jak pieść do nosa, AMD to javascript czyli głownie (tylko) GUI a DDD to zestaw wzorców dla Modelu Dziedziny (w MVC) czyli na pewno nie GUI.

myślę że koledze chodziło o anemiczne encje + "proceduralne" przetwarzanie danych w "serwisach" a nie jak w skrajnie odmiennym DDD. Dodając od siebie że DDD to kolejny promowany ustrój w praktyce może skłania się ku lepszej izolacji poszczególnych obiektów ale wiąże się że sporymi kompromisami (zeby nie powiedzieć wprost antypatternami) na warstwie technologicznej przynajmniej w typowej aplikacji JEE z JPA. Więc DDD wedlug mnie wcale nie jest kluczem do sukcesu, raczej w pewnych określonych (i moim zdaniem wcale nie czestych sytuacjach) lepszy od innych podejść w tym klasycznego operatego o przetwrzanie proceduralne na encjach anemicznych któe wedlug mnie świetnie sie sprawdza w developerce do określonego poziomu skomplikowania procesów biznesowych + rozmiaru zespołu developerskiego.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: We are not OOP programmers anymore

Jarosław S.:
Dodając od siebie że DDD to kolejny promowany ustrój w praktyce może skłania się ku lepszej izolacji poszczególnych obiektów ale wiąże się że sporymi kompromisami (zeby nie powiedzieć wprost antypatternami) na warstwie technologicznej przynajmniej w typowej aplikacji JEE z JPA.

jakimi?

Więc DDD wedlug mnie wcale nie jest kluczem do sukcesu, raczej w pewnych określonych (i moim zdaniem wcale nie czestych sytuacjach) lepszy od innych podejść w tym klasycznego operatego o przetwrzanie proceduralne na encjach anemicznych któe wedlug mnie świetnie sie sprawdza w developerce do określonego poziomu skomplikowania procesów biznesowych + rozmiaru zespołu developerskiego.

czym tu są owe anemiczne encje? Pomijając "bałagan" jakiego trudno uniknąć mając setki wywołujących się wzajemnie funkcji, pozostaje problem z danymi w modelu relacyjnym: w żyjącym systemie relacyjny model danych nie poddaje się stałemu rozwojowy (przybywające elementy dziedzinowe).
Jarosław Szczepankiewicz

Jarosław Szczepankiewicz Lead Technical
Consultant

Temat: We are not OOP programmers anymore

Jarosław Ż.:
Jarosław S.:
Dodając od siebie że DDD to kolejny promowany ustrój w praktyce może skłania się ku lepszej izolacji poszczególnych obiektów ale wiąże się że sporymi kompromisami (zeby nie powiedzieć wprost antypatternami) na warstwie technologicznej przynajmniej w typowej aplikacji JEE z JPA.

jakimi?

encje anemiczne wynikają z zalecanego przez JPA sposobu oddzielenia operacji zmiany stanu na encjach od operowaniu na EntityManagerze (który w modelu anemicznym występuje gdzieś w warstwie serwisowej). O ile dobrze pamiętam moje podejście do DDD jakiś czas temu to każda "gruba encja" z DDD może i ma obowiązek sama operować na zachowaniu stanu czyli bezpośrednio na EntityManagerze. A więc zaczyna być świadoma wszelkich technicznych rzeczy jak atrybuty transakcji, jej zasieg, strategią lockowania itp. Według specyfikacji JPA jest to antypattern.
Więc DDD wedlug mnie wcale nie jest kluczem do sukcesu, raczej w pewnych określonych (i moim zdaniem wcale nie czestych sytuacjach) lepszy od innych podejść w tym klasycznego operatego o przetwrzanie proceduralne na encjach anemicznych któe wedlug mnie świetnie sie sprawdza w developerce do określonego poziomu skomplikowania procesów biznesowych + rozmiaru zespołu developerskiego.

czym tu są owe anemiczne encje?

http://en.wikipedia.org/wiki/Anemic_domain_model
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: We are not OOP programmers anymore

Jarosław S.:
encje anemiczne wynikają z zalecanego przez JPA sposobu oddzielenia operacji zmiany stanu na encjach od operowaniu na EntityManagerze (który w modelu anemicznym występuje gdzieś w warstwie serwisowej).

czyli jest to zalecenie rezygnacji z paradygmatu obiektowego

O ile dobrze pamiętam moje podejście do DDD jakiś czas temu to każda "gruba encja" z DDD może i ma obowiązek sama operować na zachowaniu stanu czyli bezpośrednio na EntityManagerze. A więc zaczyna być świadoma wszelkich technicznych rzeczy jak atrybuty transakcji, jej zasieg, strategią lockowania itp. Według specyfikacji JPA jest to antypattern.

JPA to (o ile się nie mylę) pomiot mało obiektowego a bardziej funkcyjnego EJB

Więc DDD wedlug mnie wcale nie jest kluczem do sukcesu, raczej w pewnych określonych (i moim zdaniem wcale nie czestych sytuacjach) lepszy od innych podejść w tym klasycznego operatego o przetwrzanie proceduralne na encjach anemicznych któe wedlug mnie świetnie sie sprawdza w developerce do określonego poziomu skomplikowania procesów biznesowych + rozmiaru zespołu developerskiego.

czym tu są owe anemiczne encje?

http://en.wikipedia.org/wiki/Anemic_domain_model

znam ten antywzorzec... dlatego go przywołałem
Marcin Mroczkowski

Marcin Mroczkowski Programista JAVA/JEE

Temat: We are not OOP programmers anymore

Jarosław S.:O ile dobrze pamiętam moje podejście do DDD jakiś czas temu to każda "gruba encja" z DDD może i ma obowiązek sama operować na zachowaniu stanu czyli bezpośrednio na EntityManagerze. A więc zaczyna być świadoma wszelkich technicznych rzeczy jak atrybuty transakcji, jej zasieg, strategią lockowania itp. Według specyfikacji JPA jest to antypattern.

Jest to nie tylko antipattern nie tylko dla JPA, ale i dla DDD też. Encje powinny być możliwie najprostszymi obiektami zawierającymi logikę biznesową i stan, a ich utrwalaniem powinno zajmować się repozytorium. Można oczywiście zadecydować o częściowym odejściu od tej zasady, ale warto pamiętać, że stopniowo związujemy domenę z technologią bazy danych.
Jarosław Ż.:
JPA to (o ile się nie mylę) pomiot mało obiektowego a bardziej funkcyjnego EJB

JPA to tylko i wyłącznie specyfikacja mapowania ORM, dostarczana standardowo z JEE. Nie narzuca w żaden sposób architektury aplikacji (potrafi zmapować praktycznie dowolne obiekty w javie), dostarcza manager encji i technologię mapowania (adnotacje/xml).
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: We are not OOP programmers anymore

Marcin M.:
Jest to nie tylko antipattern nie tylko dla JPA, ale i dla DDD też. Encje powinny być możliwie najprostszymi obiektami zawierającymi logikę biznesową i stan, a ich utrwalaniem powinno zajmować się repozytorium.

ano, proste "encje" często są "tworzywem" poważnych agregatów, a te są "dość mądre", nie są też całkiem głupie bo wyposażone w ValueObject jako atrybuty, same się kontrolują (podstawowa logika biznesowa).
Można oczywiście zadecydować o częściowym odejściu od tej zasady, ale warto pamiętać, że stopniowo związujemy domenę z technologią bazy danych.

a tego właśnie chcemy tu uniknąć

Jarosław Ż.:
JPA to (o ile się nie mylę) pomiot mało obiektowego a bardziej funkcyjnego EJB

JPA to tylko i wyłącznie specyfikacja mapowania ORM, dostarczana standardowo z JEE.

gdzie ORM powstał (jak sama nazwa wskazuje) głównie do mapowania obiektowej logiki na relacyjne utrwalanie, jest to jeden z głównych zabójców wydajności i rozszerzalności (modyfikowalności) aplikacji
Nie narzuca w żaden sposób architektury aplikacji (potrafi zmapować praktycznie dowolne obiekty w javie), dostarcza manager encji i technologię mapowania (adnotacje/xml).

i własnie: "nie narzuca"
Jarosław Szczepankiewicz

Jarosław Szczepankiewicz Lead Technical
Consultant

Temat: We are not OOP programmers anymore

Jarosław Ż.:
gdzie ORM powstał (jak sama nazwa wskazuje) głównie do mapowania obiektowej logiki na relacyjne utrwalanie, jest to jeden z głównych zabójców wydajności i rozszerzalności (modyfikowalności) aplikacji

pozwolę się nie zgodzić, a przynajmniej nie na tak "radykalne" wnioski. Aplikację bazodanową w ORM zamiast w SQL tworzy się z reguły szybciej (w czystym JDBC trzeba i tak zrobić "swoje mapowanie" na obiekty DTO / encje i dorobić operacje zapisu / odczytu) i z mniejszą błedogennością niż w JDBC. Dodatkowo konserwacja jest znacznie prostsza przy dużej liczbie relacji mapowanej na JOINy itp. bo zmiana jest w jednym miejscu a nie w kilku/nastu/dziesięciu, automatycznie "propagowanie" zmian w mapowaniu są znacznie prostsze niż w JDBC. To są zalety. Co do wydajności to jest to też trochę kontrowersyjna teza. Jest narzut dodatkowy z ORM'a i czasami jest wymagane podpatrywanie ORM'a jak tłumaczy sobie zapytania, ale też są cache L1 i L2 które przy bogatym grafie encji mocno potrafią pomóc. Według mnie nie powinno się generalizować na temat JDBC vs ORM co do wydajności, bo jak to w wielu innych miejscach w technologii "to zależy".
Jarosław Szczepankiewicz

Jarosław Szczepankiewicz Lead Technical
Consultant

Temat: We are not OOP programmers anymore

Jarosław Ż.:
http://en.wikipedia.org/wiki/Anemic_domain_model

znam ten antywzorzec... dlatego go przywołałem

Ten "antywzorzec" jak go nazywasz często świetnie się sprawdza w praktyce w bardzo dużej części projektów, a dowodem jest sukces takich frameworków jak Spring, Hibernate itp. które promowały / promują model anemiczny i są kamieniami milowymi w developmencie IT.

konto usunięte

Temat: We are not OOP programmers anymore

Jarosław S.:
Jarosław Ż.:
Jarosław S.:
Dodając od siebie że DDD to kolejny promowany ustrój w praktyce może skłania się ku lepszej izolacji poszczególnych obiektów ale wiąże się że sporymi kompromisami (zeby nie powiedzieć wprost antypatternami) na warstwie technologicznej przynajmniej w typowej aplikacji JEE z JPA.

jakimi?

encje anemiczne wynikają z zalecanego przez JPA sposobu oddzielenia operacji zmiany stanu na encjach od operowaniu na EntityManagerze (który w modelu anemicznym występuje gdzieś w warstwie serwisowej). O ile dobrze pamiętam moje podejście do DDD jakiś czas temu to każda "gruba encja" z DDD może i ma obowiązek sama operować na zachowaniu stanu czyli bezpośrednio na EntityManagerze. A więc zaczyna być świadoma wszelkich technicznych rzeczy jak atrybuty transakcji, jej zasieg, strategią lockowania itp. Według specyfikacji JPA jest to antypattern.

Tutaj jako ciekawostkę dodam - istnieją ORM'y (np. Lightspeed na .NET, nie orientuje się jak wygląda sprawa w wypadku Javy) które pozwalają na pobieranie / modyfikowanie "pod obiektów" danej encji poprzez zwykłe wywołanie funkcji / property na obiekcie (encji - rodzicu) biznesowym bez bezpośredniego udziału odpowiednika EntityManagera.

Zasięg jest ustalany dynamicznie.

Niestety (?) strategię lockowania i jak cały proces inicjujący trzeba zdefiniować w warstwie serwisu.

Z resztą - chyba ciężko wyobrazić sobie sobie DDD które zarządza transakcją i "samo siebie" wywołuje. Za to powinna odpowiadać warstwa "technologiczna" a nie biznesowa. Pewnie dlatego EntityManager w DDD to antypattern.Ten post został edytowany przez Autora dnia 29.09.13 o godzinie 20:59

Następna dyskusja:

message Servlet is not ava...




Wyślij zaproszenie do