Jackson serializowanie encji

Witam mam aplikację w której wystawiam API RESTowe w Springu i wypluwam dane JSON. W przypadku serializowania encji z polami LAZY dostaje oczywiście Exception, bo po wyjściu z transakcji nie może mi ich serializować. Znalazłem kilka rozwiązań problemu ale nie wiem które wybrać i czy są to jedyne rozwiązania.

1. jackson-module-hibernate - w jego przypadku nie wiem jak z community oraz utrzymaniem projektu
2. Spring Data REST - w tym przypadku wolał bym pozostać przy idei @Controlerów, mieć ujednolicony sposób wysyłania danych.

I moje pytanie czy to są jedyne opcje poradzenia sobie z tym problemem? Jeżeli tak to który wybrać? Jakie znacie inne rozwiązania?

Powiedz jacksonowi aby nie serializował pól które są złożone czyli relacje one-to-one itp.

A w ogóle ostatnią rzeczą jaką bym robił to tworzenie API na bazie modelu bazy danych ale powodzenia

Szczery jesteś;) Czyli proponujesz DTO??

Dokładnie :). Model bazy jest twoją prywatną sprawą. To, że wszyscy pchają encje gdzie się da to jest tylko i wyłącznie zabieg marketingowy w przykładach HelloWold frameworkow. W praktyce oznacza to problemy

@rybex ale jakiego efektu oczekujesz?
Chcesz przesłać tylko część danych, tzn te wszystkie powiąznia lazy olać? To zrób nowe klasy DTO do przechowywania danych.
Chcesz mieć te dane? Napisz odpowiednie zapytanie jpql / hql którym zrobisz joiny przy pobieraniu danych z bazy.
Osobiście połączyłbym oba sposoby.

Bawienie się w przesyłanie obiektów encyjnych gdziekolwiek uważam za bardzo ryzykowne i błędogenne. Szczególnie jeśli transakcje masz możliwie wysoko, tzn na przykład gdzieś na poziomie serwisu. Widywałem już takie błędy w większych projektach gdzie ktoś pchał obiekty encyjne do widoku / używał jako beanów do obierania danych z formularzy i potem działy się cuda na kiju jak pojawianie się dziwnych wpisów w bazie / znikanie wpisów w bazy.
Ktoś na przykład pobrał z DAO listę obiektów a potem sobie ją modyfikował / filtrował / uzupełniał przed wysłaniem do warstwy widoku, tylko nie zauważył że transakcja jest cały czas aktywna więc modyfikując tą listę powodował zmiany w bazie...

To generalnie bardzo kusząca perspektywa, ale faktycznie często przysparza wielu problemów. Hibernatowe encje w runtimie są opakowane w obiekty proxy przez co np. mogą zdarzyć się nieskończone cykliczne referencje w niektórych bibliotekach (Jackson, HAL-builder). Napisanie jakiejś małej warstwy które na podstawie np. dozera będzie transformować encje do DTO powinno pójść bardzo szybko i zaoszczędzić Ci sporo problemów zarówno teraz jak i w przyszłości.

Hmmm a myślałem że DTO to umierający wzorzec i np. w przypadku RESTów zostanie on wyparty.