Temat: We are not OOP programmers anymore

Jarosław S.:

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".

Mam wrażenie, że zatracamy granicę pomiędzy projektem "obiektowym" a implementacją. Nie przeczę, że pewne konstrukcje implementacji są "anemiczne" czy ORM bywa przydatny. Uważam, że złe są te implementacje, które psują projekty. Np. mając kilka niezależnych agregatów (nazwijmy jej DDD) możemy utrzymać ich niezależność stosując proste mapowanie active table lub active record, a możemy zniszczyć projekt normalizując "dane" i tworząc skomplikowane mapowanie ORM na bazę znormalizowanych danych, silnie z sobą powiązanych danych. Mi chodzi generalni eo to by nie niszczyć zalet "obiektowych" projektów (hermetyzacja, brak wzajemnych powiązań itp.)

Temat: We are not OOP programmers anymore

Jarosław Ż.:
Mam wrażenie, że zatracamy granicę pomiędzy projektem "obiektowym" a implementacją. Nie przeczę, że pewne konstrukcje implementacji są "anemiczne" czy ORM bywa przydatny. Uważam, że złe są te implementacje, które psują projekty. Np. mając kilka niezależnych agregatów (nazwijmy jej DDD) możemy utrzymać ich niezależność stosując proste mapowanie active table lub active record, a możemy zniszczyć projekt normalizując "dane" i tworząc skomplikowane mapowanie ORM na bazę znormalizowanych danych, silnie z sobą powiązanych danych. Mi chodzi generalni eo to by nie niszczyć zalet "obiektowych" projektów (hermetyzacja, brak wzajemnych powiązań itp.)

ORM nie jest wcale wrogiem rozwiązań, o których piszesz. DDD zakłada niezależność domeny od implementacji. Mamy więc model domeny, który jest czystym wyrażeniem biznesu (obiekty z logiką i stanem), a persystencja ma za zadanie zachowywać i wyciągać stan tych obiektów. Nie ma tutaj mowy o "psuciu" zalet obiektowych modeli.
ORM bardzo pasuje do tego zadania, bo potrafi transparentnie zmapować dowolny obiekt w javie na tabele relacyjne(używając konfiguracji w XML, obiekty są 100% czyste). Wydajność modelu mapowanego w ten sposób nie musi być wysoka, bo w każdej chwili możemy zastosować CQRS, który rozwiązuje problemy wydajnościowe "ciężkich" agregatów i dzięki temu nie musimy kombinować z mapowaniami.

Temat: We are not OOP programmers anymore

Marcin M.:
ORM nie jest wcale wrogiem rozwiązań, o których piszesz. DDD zakłada niezależność domeny od implementacji. Mamy więc model domeny, który jest czystym wyrażeniem biznesu (obiekty z logiką i stanem), a persystencja ma za zadanie zachowywać i wyciągać stan tych obiektów. Nie ma tutaj mowy o "psuciu" zalet obiektowych modeli.
ORM bardzo pasuje do tego zadania, bo potrafi transparentnie zmapować dowolny obiekt w javie na tabele relacyjne(używając konfiguracji w XML, obiekty są 100% czyste). Wydajność modelu mapowanego w ten sposób nie musi być wysoka, bo w każdej chwili możemy zastosować CQRS, który rozwiązuje problemy wydajnościowe "ciężkich" agregatów i dzięki temu nie musimy kombinować z mapowaniami.

Piszesz o "dobrej" implementacji, ja piszę o przypadkach nagminnego tworzenia znormalizowanych modeli danych "pod" aplikację.... :)

Temat: We are not OOP programmers anymore

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.

Wydaje mi się, że owy spring w obecnej wersji bardziej "skłania" się ku DDD. Takie projekty jak spring data, gdzie zmieniła się filozofia podejścia do utrwalania danych, zamiast dao -> repositories. Nie mówiąc już o innych projektach spring integration, czy spring reactor które z pewnością pomagają zaprojektować aplikację w oparciu o DDD.

Zresztą warto zobaczyć : http://www.youtube.com/watch?v=gjhA-he3PVoTen post został edytowany przez Autora dnia 30.09.13 o godzinie 21:07

Temat: We are not OOP programmers anymore

Łukasz W.:

Wydaje mi się, że owy spring w obecnej wersji bardziej "skłania" się ku DDD. Takie projekty jak spring data, gdzie zmieniła się filozofia podejścia do utrwalania danych, zamiast dao -> repositories.

to że pojawiają się jakieś prezentacje na temat jak zrobić DDD z użyciem springa nie jest dowodem na to że autorzy springa "odwracają" się od koncepcji anemicznego modelu jako czegoś złego. Kilka przykładów:

(JDBC) http://spring.io/guides/gs/relational-data-access/
(JPA) http://spring.io/guides/gs/accessing-data-jpa/
(MONGO) http://spring.io/guides/gs/accessing-data-mongo/
(GEMFIRE) http://spring.io/guides/gs/accessing-data-gemfire/

nie jestem specem od DDD ale powyższe jak dla mnie to zwykłe encje anemiczne których stan zarządzany jest poza nimi samymi.

Nie mówiąc już o innych projektach spring

integration, czy spring reactor które z pewnością pomagają zaprojektować aplikację w oparciu o DDD.

ja bym raczej użył sformułowania nie przeszkadzają w DDD dla tych którzy chcą użyć DDD. Znakomita większość literatury na temat spring, hibernate używała i używa encji anemicznych.

Temat: We are not OOP programmers anymore

Jarosław S.:
Znakomita większość literatury na temat spring, hibernate używała i używa encji anemicznych.

podobnie jak obecny uczelniany system kształcenia:

funkcje + dane = programy

to świat lat 80-tych

obserwuję postępy edukacji i niestety są znacznie wolniejsze niż postępy "pozauczelniane".

Anemiczne modele to relikty powyższego "wzoru". Czy lepsze? Ja mam miernik w postaci wycenianych nakładów pracy na zmiany i rozwijanie: prucie baz danych, refaktoring i migracje do "kolejnych nowych modeli danych"... to anemiczne modele na modelu relacyjnym bazy dla całego systemu.

Większość o niczym tu nie świadczy, podobnie jak na uczelniach na których nadal w zasadzie nie uczy się studentów metod obiektowych.

Troszkę się "uniosłem" ;) ale niestety stale oglądam oferty developerów: "większość" nie ma racji: są najdrożsi....