tag:blogger.com,1999:blog-5197374494377847819.post5742893297598760278..comments2024-03-22T22:13:46.650+01:00Comments on Holistycznie o inżynierii oprogramowania: Racjonalne wykorzystanie JPASławek Sobótkahttp://www.blogger.com/profile/15082577671795313109noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-5197374494377847819.post-40111628170789415542012-10-30T23:55:01.777+01:002012-10-30T23:55:01.777+01:00Jeszcze z ciekawych podejść do problemu jest pomys...Jeszcze z ciekawych podejść do problemu jest pomysł Reporting Database opisywany przez Fowlera i Evansa:<br /><br />http://martinfowler.com/bliki/ReportingDatabase.html<br /><br />Koncept bardzo ciekawy i w sumie rozszerzalny.Rafihttps://www.blogger.com/profile/11590219329534915077noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-28866398421009588372012-10-16T00:19:19.010+02:002012-10-16T00:19:19.010+02:00"Enterprise" nie jedno ma imię:)
Wystar..."Enterprise" nie jedno ma imię:)<br /><br />Wystarczy wyobrazić sobie ekran z podglądem produktu przed jego zakupem, gdzie sugerujemy zamienniki/produkty dodatkowe z grafu powiedzmy znajomych, którzy również kupili ten produkt. Wówczas można rozważyć oparcie Read Modelu noSql grafowy.<br /><br />Ale generalnie widzę, że się zgadzamy, chyba tylko rozjechały się nam konteksty - dlatego warto skupić uwagę na konkretnych przykładach. Bo w CqRS generalnie o to chodzi, że może istnieć model domenowy (transakcyjny) i pewne "projekcie" danych (ale nie wszystkich, zwykle wybranych ze względu na wydajność lub specyfikę - np wspomniany graf). Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-65217679073777469352012-10-15T13:57:59.747+02:002012-10-15T13:57:59.747+02:00Aha i jeszcze uwaga numer 2 :), żeby nie było, że ...Aha i jeszcze uwaga numer 2 :), żeby nie było, że bredzę :).<br /><br />Oczywiście, jeśli potrzebujemy zrobić zestawienie statystyczne/wykres to to jest w ogóle inaczej postawiony problem. Oczywiście można by teoretycznie wyciągnąć 10000 obiektów biznesowych, przełożyć do DTO i wykonać analizę, no ale to gołym okiem widać, że zalatuje absurdem.<br /><br />Więc w momencie kiedy Pan pisze o zestawieniach statycznych/wykresach to trzeba zmienić narzędzie. To jest wredny problem, do którego podchodziłem wiele razy na różne sposoby. Na dziś unikam SQL/HQL i wolę pójść w przetwarzanie takich danych "z boku" i trzymanie sobie zdenormalizowanych danych pomocniczych tak jak robi się to w hurtowaniach. Bo skoro mamy tych obiektów 100 000 i musimy wytworzyć analizę to zaczynamy wychodzić poza system transakcyjny i przechodzić do systemu typu hurtownia.<br /><br />Bo skoro już dyskutujemy o narzędziach to trzeba pamiętać, że DDD jest narzędziem przeznaczonym głównie do systemów transakcyjnych, a nie analitycznych. W systemach analitycznych podejście się nie sprawdzi, bo główna zaleta DDD czyli spójność modelu (tak dla odczytu jak i zapisu) ma jednocześnie duży koszt i kompletnie żadnego sensu na w zastosowaniach analitycznych gdzie "model" traci w dużym stopniu sens, a zapisów po prostu nie ma, czyli nie ma co się wysilać.Rafihttps://www.blogger.com/profile/11590219329534915077noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-63323335360072192922012-10-15T13:47:33.707+02:002012-10-15T13:47:33.707+02:00Raczej bym powiedział, że to jest ostatnia deska r...Raczej bym powiedział, że to jest ostatnia deska ratunku :).<br /><br />Przepakowywanie w DTO. Po pierwsze przepakowywanie można zrobić optymalnie i nieoptymalnie. Zawsze jest kwestia tego na co możemy sobie pozwolić, niemniej jeśli chodzi o moje zdanie, to przy aplikacjach klasy enterprise, jeśli możemy sobie pozwolić na sprzęt to jest to całkiem niezły pomysł. Dlaczego? Bo:<br />1. Nie psujemy w ten sposób architektury.<br />2. Programista nie musi mieć rozległej wiedzy o strukturach danych, co przy dużej rozległości projektach jest sporą zaletą i elegancko zwiększa hermetyzację i ułatwia zarządzanie projektem.<br />3. Usuwamy wszystkie problemy związane z Lazy Loading, jeśli korzystamy np. z Hibernate.<br /><br />O Java i technologie pokrewnych można powiedzieć wiele, ale nie to, że są wydajne (w sensie jednostkowym). Po to stworzono szereg technologii z szeroko pojętej skalowalności, żeby móc zachować dobrą architekturę. Ja kieruję się (przy poziomie enterprise) zasadą, że wolę dopłacić za dodatkową maszynę niż po 2 latach zastanawiać się czy kod da się jeszcze zmieniać czy już można tylko zaorać :).Rafihttps://www.blogger.com/profile/11590219329534915077noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-91185253419551995662012-10-15T13:15:09.423+02:002012-10-15T13:15:09.423+02:00Zgadza się, koszty utrzymania są duże, dlatego &qu...Zgadza się, koszty utrzymania są duże, dlatego "maksymalna" separacja w CqRS jaką jest stworzenie osobnego modelu do odczytu jest:<br />- ostatnią fazą optymalizacji<br />- nie stosujemy jej w całej rozciągłości projektu<br /><br />Natomiast co do pobierania danych domenowych i ich przepakowywania w obiekty transferowe, to będzie działać chyba raczej przy niedużym obciążeniu... (zależy jeszcze od sprzętu:)Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-32210043987453996662012-10-15T11:10:51.033+02:002012-10-15T11:10:51.033+02:00Wyszukiwanie na potrzeby UI jest zwykle wyszukiwan...Wyszukiwanie na potrzeby UI jest zwykle wyszukiwaniem jednocześnie na potrzeby operacji biznesowych. Jeśli mam UI, który składa się z tabeli prezentującej zamówienia w trakcie realizacji to muszę znać model domenowy, żeby wiedzieć co to w praktyce znaczy "zamówienie w trakcie realizacji" (czy cokolwiek sobie tu wstawimy, zawsze będzie to jakieś kryterium wyszukiwania). Wobec czego jak dla mnie UI budowane jest NAD modelem domenowym, a nie jak Pan proponuje OBOK i do mnie trafia rozwiązanie, w którym CQRS budujemy NAD modelem domenowym. Jeśli użyjemy CQRS obok i zaczniemy sobie SQLem wyciągać coś z bazy to mamy 2 miejsca, w których dublujemy wiedzę o strukturach danych. Jeśli jedynym zyskiem jest tutaj szybkość, to mam wrażenie, że jest to zysk obarczony za dużymi kosztami.Rafihttps://www.blogger.com/profile/11590219329534915077noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-75352376072949774882012-10-15T10:50:23.320+02:002012-10-15T10:50:23.320+02:00Repo zarządza agregatem: pobiera po numerze/id, ut...Repo zarządza agregatem: pobiera po numerze/id, utrwala<br /><br />Ew. może wyszukiwać agregaty na potrzeby operacji biznesowych, np: wyszukaj niezatwierdzone zamówienia danego użytkownika - ponieważ chcemy in nadać rabaty.<br /><br />Natomiast wyszukiwanie na potrzeby UI, to już odpowiedzialność poza Repo - np "zwykłe" serwisy wyszukujące. No i tutaj zaczyna się walka o wydajność:PSławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-71684677592170923032012-10-15T10:29:00.317+02:002012-10-15T10:29:00.317+02:00Dla mnie generalnie jeśli mówimy o DDD to wyszukiw...Dla mnie generalnie jeśli mówimy o DDD to wyszukiwanie obiektów musi się odbywać przez stosowne Repository. To jak ono zostanie zaimplementowane to jest druga sprawa, ale nie wyobrażam sobie posługiwania się SQLem czy HQLem na poziomie API domeny. I w sumie pod kątem efektywności wydobywania informacji to właśnie mamy pole do popisu na poziomie implementacji Repository i tutaj zaczyna się cała zabawa jak to zrobić. SQL jest jakimś wyjściem, natomiast to jest ryzykowna decyzja i musi być podjęta świadomie i z automatu nakłada na oprogramowanie pewne ograniczenia, którego wszyscy "shareholders" powinni być świadomi.Rafihttps://www.blogger.com/profile/11590219329534915077noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-32245883641718558032012-10-10T22:14:35.807+02:002012-10-10T22:14:35.807+02:00tak, jest to jakieś podejście. Czasem jedyne z dos...tak, jest to jakieś podejście. Czasem jedyne z dostępnych - jeżeli spójność jest wymogiem. Ale jeżeli nie jest, to próbując stworzyć jeden model, który będzie służył zarówno do zapisu jak i do odczytu wprowadzamy złożoność przypadkową (w sensie http://en.wikipedia.org/wiki/Accidental_complexity ), która zawsze się "mści" podczas rozbudowy i utrzymania:) Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-51474407903007670942012-10-10T22:09:39.457+02:002012-10-10T22:09:39.457+02:00A może denormalizacja i indeksowanie?A może denormalizacja i indeksowanie?Rafihttps://www.blogger.com/profile/11590219329534915077noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-996019026847535192012-06-24T23:04:36.201+02:002012-06-24T23:04:36.201+02:00Różne są sytuacje - warto znać różne podejścia i n...Różne są sytuacje - warto znać różne podejścia i narzędzia...<br /><br />Pomijając już shreding.<br /><br />Ogólny kontekst persystencji (SessionFactory/EntityManagerFactory) musi ze swej natury "stać na" puli połączeń READ/WRITE. Jeżeli wiem, że będę czytał, wówczas mogę zestawić pulę połączeń READ (ONLY) - niektóre bazy będą działać nieco szybciej.<br /><br />Oczywiście można na tej drugiej puli postawić drugi kontekst persystencji - ale po co...Sławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-72505324218391078602012-06-22T08:59:16.186+02:002012-06-22T08:59:16.186+02:00Nie łączę dwóch mapperów ORM w jednej aplikacji. H...Nie łączę dwóch mapperów ORM w jednej aplikacji. Hibernate udostępnia "NamedQuery", które można trzymać w pliku XML i mogą to być zapytania HQL jak i SQL. Obiekty DTO odczytuję zapytaniami SQL z NamedQuery, w operacjach wyszukiwania z GUI korzystam z HibernateCriteria i obiekt DTO jest zmapowany na widok. Jeśli używam Hibernate, nie jest mi już potrzebny IBatis.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-79965679942215295762012-03-02T20:24:51.261+01:002012-03-02T20:24:51.261+01:00No tak!!!
młotek do gwoździ
wkrętak do wkrętów
zap...No tak!!!<br />młotek do gwoździ<br />wkrętak do wkrętów<br />zapamiętać!!<br /><br />A mówiąc serio, to przychodzą mi do głowy 2 przykłady potwierdzające Twoje zdanie. <br />1. Command<br /><br />Załóżmy, że mamy tabelę bazodanową z 20 kolumnami, gdzie 5 z tych kolumn jest powiązana kluczami obcymi z innymi tabelami.<br />Przyglądnijmy się teraz wydajności bazy przy zmianie 1 atrybutu obiektu odwzorowującego tą tabelę. <br />Wartośc zmienianego atrybutu nie jest ograniczona kluczem obcym.<br /> <br />A) Hibernate: wykona update 1 kolumny dynamicznie budując zapytanie DML<br />B) myBatis: zapewne ze względu na 1 operację "update" w DAO wykona update wszystkich kolumn tabeli<br /><br />W podejśu A oszczędzimy bazie danych weryfikacji spójności kluczy obcych.<br />W podejściu B musimy liczyć Się z dużo większą pracą związaną z tworzeniem dopasywanych do przypadku użycia poleceń SQL.<br /><br />Do DDL wybieram A.<br /><br />2. Query<br />Powiedzmy, że w naszej aplikacji pojawiło się zapytanie(query), które rozgrzewa do czerwoności macierz dyskową i procek podgrzewając temperaturę w mieście o 0,5 stopnia.<br />Administrator zwrócił nam raport pokazujący obciążające zapytanie.<br /><br />Jak odnaleźć winowajcę?<br />A) Hibernate: wykonać "reverse magic ORM" i odnaleźć zapytanie w HQL<br />B) myBatis: wyszukać fragment zapytania w plikach XML(preferuję rozdzielenie zapytań SQL od kodu Java)<br /><br />Do zapytań wybieram B.<br /><br />Pozdrawiam,Maciej Hadamhttps://www.blogger.com/profile/04210378708959480135noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-20998486974089130362012-03-02T18:56:37.185+01:002012-03-02T18:56:37.185+01:00Dokładnie o to chodzi...
btw: warto obadać http://...Dokładnie o to chodzi...<br />btw: warto obadać http://www.mybatis.org/core/statement-builders.htmlSławek Sobótkahttps://www.blogger.com/profile/15082577671795313109noreply@blogger.comtag:blogger.com,1999:blog-5197374494377847819.post-8495989059423941902012-03-02T18:50:20.266+01:002012-03-02T18:50:20.266+01:00Po części ze względu na legacy, po części ze wzglę...Po części ze względu na legacy, po części ze względu na smutek ziejący z tabelek, pomieszaliśmy ostatnio jdbcTemplate i JPA i nawet fajnie było.agshttps://www.blogger.com/profile/15353176001507790216noreply@blogger.com