Java EE 6 - wzór trwałych obiektów domenowych - jakieś sukcesy?

Question

Mam umiarkowanie złożoną aplikację korzystającą z POJO, a teraz przyjmuję ją do migracji do EJB3.1, dzięki czemu można ją wdrożyć online, dostęp do niej za pośrednictwem usług REST i korzystanie ze środowiska kontenerowego (trwałość jest najważniejsza, ale transakcje byłyby użyteczne także).

Byłem z dala od Java EE od czasów J2EE, i walczę o to, aby zrozumieć moją "stratę" fasoli encji. Zajęło mi trochę czasu uświadomienie sobie, że Encje w EJB3.1 nie są tak naprawdę fasolami w starym sensie ... :) Czytałem wiele książek EJB3, w tym podręcznik "Java" 3.1 Java "O'Reilly Enterprise", z których wszystkie wyjaśniają koncepcje i komponenty EJB3, ale nie opcje wzorca implementacji.

W moich badaniach i dochodzeniach poszukujących wzorów Java EE 6, jestem raczej przyjęta przez podejście Adama Biena - szczególnie wzór "Persistent Domain Objects" (PDO) (w swojej książce, ale także skrócony tutaj: http://download.java.net/general/podcasts/real_world_java_ee_patterns.pdf), który pojawia się oferować najmniejszą złożoność i największą synergię z moją obecną aplikacją POJO. ChNP również ściśle dostosowuje się do tradycyjnych filozofii i podejścia zorientowanego na obiekt i naprawdę mi się podoba.

Zamiast zastanawiać się nad debatą na temat ChNP, chciałbym usłyszeć od osób, które ją wdrożyły i co zadziałało, a które napotkały trudności. W szczególności chciałbym dowiedzieć się, w jaki sposób nawiązano połączenia z z jednostek WZP na inne usługi w kontenerze (np. Połączenia z bezstanowymi zasobami sesji itp.).

Chciałbym również wiedzieć, czy istnieją alternatywy dla wzorca PDO, które pozwalają mi zachować strukturę aplikacji (używając polimorfizmu itp.) Bez konieczności tworzenia komponentu bean sesji i jednostki JPA dla każdej klasy w moim modelu. (Nie chcę tego robić częściowo z powodu ogromnych ćwiczeń wymaganych do refaktoryzacji wszystkich testów jednostkowych i integracyjnych, a częściowo dlatego, że - o ile widzę - skończę próbować replikować moją 1toMany w całej mojej fascynacji sesyjnej, która wydaje się szalona).

Czy ktoś ma jakieś doświadczenia dzielić się - lub jeśli chcesz, aby podkreślić, że jestem idiotą i coś przeoczyć podstawowych w Java EE 6, która byłaby „mile widziane” zbyt :)

TIA

Answer 1

Nie odpowiada, więc może jestem jedynym robi;) dla nikogo szuka wskazówek, znalazłem:

• Twój obiekt modelu potrzebuje znacznym modyfikacjom. Nie możesz używać Map ani List interfejsów, jak w aplikacji non-JPA, ponieważ JPA nie może "obsługiwać" interfejsów, musisz utrzymywać (abstrakcyjne) klasy. Hibernate ma adnotację @Any i @ManyToAny, ale obciążenie narzutowe ( (wydajność, funkcjonalność i kodowanie) jest znaczące (IMHO). Jeśli masz , możesz zaimplementować ohydną hierarchię klas abstrakcyjnych, powinieneś. YUK!

• Jeśli masz nieco skomplikowany model obiektowy (więcej niż sześć relacji między obiektami), otrzymasz wiele poleceń JOIN w kodzie SQL wygenerowanym przez silnik JPA. Czytałem gdzieś, że> 6 JOINS kładzie duży nacisk na bazę danych (jestem pewna, że ​​jest to reguła prawidłowa). MySQL ma sztywny limit 61 połączeń. Brzmi szaleńczo wysoko, na pewno nigdy byś tego nie dotknął! Jeśli masz hierarchię obiektów abstrakcyjnych i kilka relacji między obiektami, to wkrótce się to sumuje!

Nie znalazłem sposobu na obejście pierwszego "problemu".Czuje się źle wbijanie wielu abstrakcyjnych klas bazowych zamiast interfejsów, ale jest to nieuniknione, o ile widzę. Proszę powiedz mi, jeśli nie!

Drugi problem można zarządzać za pomocą leniwego pobierania relacji między obiektami lub za pomocą wzorca bramy Adama i sesji rozszerzonej trwałości (zamiast bezstanowych komponentów bean sesji ładowanie i zapisywanie modelu przy każdym wywołaniu). Idę z tym ostatnim do tej pory - ale nie doszedłem do punktu, w którym mogę przetestować obciążenie pamięci i bazy danych. Zobaczymy!