Zauważyłem więc, że zdecydowanie mam tendencję do wzorowania moich obiektów stosu Spring / Hibernate w ten sposób:

Kontroler Foo dzwoni do „FooService”FooService wywołuje metodę FooRepository.getById (), aby uzyskać trochę Foos.FooRepository wywołuje niektóre wywołania Hibernate do ładowania obiektów Foo.FooService wykonuje pewne interakcje z Foos. Może wykorzystywać powiązaną usługę TransactionalFooService do obsługi rzeczy, które muszą być wykonane razem w transakcji.FooService prosi FooRepository, aby zapisać Foos.

Problem polega na tym, że Foos nie mają żadnej prawdziwej logiki. Na przykład, jeśli wiadomość e-mail musi być wysyłana za każdym razem, gdy wygasa Foo, nie ma połączenia z Foo.expire (). Jest wywołanie FooService.expireFoo (fooId). Jest to z wielu powodów:

Irytujące jest uzyskiwanie dostępu do innych usług i obiektów z Foo. To nie jest wiosenna fasola i została załadowana przez Hibernate.To denerwujące, że Foo robi kilka rzeczy transakcyjnie.Trudno zdecydować, czy Foo powinien być odpowiedzialny za wybór, kiedy się zapisać. Jeśli zadzwonisz do foo.setName (), czy foo nie zmieni tej zmiany? Czy powinien czekać, aż wywołasz foo.save ()? Czy foo.save () wywołuje po prostu FooRepository.save (to)?

Z tego powodu moje obiekty w domenie Spring mają tendencję do bycia gloryfikowanymi strukturami z pewną logiką walidacji. Może to w porządku. Może serwisy internetowe są w porządku jako kod proceduralny. Być może w miarę pisania nowych funkcji dopuszczalne jest tworzenie nowych usług, które zajmują się tymi samymi starymi obiektami na nowe sposoby.

Ale chciałbym uciec od tego rodzaju projektów i zastanawiam się, co inne zastosowania Springa z tym robią? Czy walczysz z nim za pomocą fantazyjnych sztuczek, takich jak tkanie w czasie ładowania (z którym nie czuję się komfortowo)? Czy masz jakąś inną sztuczkę? Czy uważasz, że procedury są w porządku?