POJO vs. DynamicBeans

Witam

Ostatnio zastanawia mnie taka sprawa. Pracuje korzystając z jednego z frameworków odwzorowań obiektowo relacyjnych. Jego filozofia działania jets taka, iz wykorzystuje do przekazania parametrów z tabel Mapy . Przez dłuższy czas wydawało mi się ,iż jest to rozwiązanie idealne ponieważ wystarczy odnotować dodanie tabeli w pliku konfiguracyjnym i nie musimy ingerować bezposrednio w klasę, która te informacje ma przechowac i zwrocić do warswty logiki. Ostatnio jednak zaczałem troszeczkę pracować z Hibernate uzywajac do przekazywania danych z tabel zwyklych obiektów POJO. Jakkolwiek przy każdej zmianie schematu bazy danych tzreba bespośrednio w nie ingerować to jednak mają ważną zaletę. Jest nią kontrola typów. Niejednokrotnie się zdarzało ,iż przy probie operacji na argumtach uzyskanych z bazy pojawiał się ClassCastException. Tutaj jednak takie błędy objawią sie już w czasie kompilacji (przy restarcie serwera trwajacym czasami okolo 10-15 minut jest to wazna dogodność). Ponadto czasem, zwłaszcza po 10 godzinach kodowania, można naprawde stzrelić głupią literówkę przy wpisywaniu nazwy propertisa ( w DynamicBeans) a używajac setterów i getterów z POJO eclipse czy inne środowisko samo podpowie nazwe metody a w najgorszym wypadku zacznie krzyczeć przy kompilacji.

Jaki są wasze doświadczenia w tym temacie? Czy spotkaliście sie z przypadkiem kiedy jedno z tych rozwiązań w jasny sposób górowało and drugim?

pzdr

Rozwiązanie z POJO góruje nad Dynamic Beans, ponieważ wada wymieniona przez Ciebie z dodawaniem nowych tabel / kolumn jest w wielu projektach bardzo łatwa do wyeliminowania. Wystarczy zmian dokonywać od razu na modelu obiektowym, brakujące tabele i pola dodadzą się w bazie same.

Witam

Słuchaj nie do końca to rozumiem ,w jaki sposób zmiany w modelu obiektowym mają wymusić samoistne zmiany w modelu bazy danych?

pzdr

PawelW napisał(a)

Słuchaj nie do końca to rozumiem ,w jaki sposób zmiany w modelu obiektowym mają wymusić samoistne zmiany w modelu bazy danych?

Ja też chętnie się dowiem jaki to sposób.

Zależy co jest modelem nadrzędnym. Jeśli dopasowujesz się do bazy danych, którą zarządza inna firma / dostałeś narzuconą, no to się nie da. Ale jeśli cały system jest tworzony u Ciebie, razem z bazą danych, to projektuje się wszystko obiektowo, a schemat bazy generuje się wprost z modelu obiektowego. Później zmiany modelu obiektowego z automatu nanoszone są na relacyjny. W hibernate: "hibernate.hbm2ddl.auto = update".

jakbym dostal ClassCastException popatrzymbym w pierwszej kolejnosci na twoje pojo definicje ewnetualnie implementowanych przez nie interfacow Comparable.

ale to tylko taki strzal

Witam

Ponieważ wątek się odswierzył podsumuję moje miesięczne zmagania z hibernate i używanymi przezeń pojo. Generalnie POJO+Genericsy=bajka. Korzystanie z tego w pewnym momencie staje się tak niezwykle naturalne i intuicyjne ,ze można zapomnieć iż w ogóle istnieje jakaś warstwa bazy danych. po prostu zamiast operaować na RepositoryItemach (dynamicBeans) ,które mogą być produktami , operuje się zwyczajnie na produktach.

PS. przyznam szczerzę ,że nie do końca rozumiem co chodzi w poście powyżej.

pzdr

Ja też nie. Ale JPA + Hibernate to jest faktycznie bajka ;) Jedyne o czym nie można zapomnieć to późniejsze zoptymalizowanie modelu relacyjnego, czyli np. dodanie indeksów.