Dylemat - logowanie zmian w obiekcie dto legacy code

Witam.

Załóżmy, że istnieje sobie pewien obiekt DTO, którego definicja jest dostarczana do aplikacji w formacie Swagger JSON.
Ten obiekt ma bardzo ważne biznesowe znaczenie i każda zmiana jego pół w pewnym serwisie XYZ musi być logowana.

Ja widzę trzy rozwiązania:

• ręcznie logować - a co za tym idzie naprawdę zaśmiecać kod i duplikować długość metody.
  Jest to moim zdaniem najprostsze i najwydajniejsze rozwiązanie w tej sytuacji.
• przed wykonaniem metody skopiować ten obiekt, i po jej wykonaniu porównać wynik z oryginałem (za pomocą refleksji)
  Skomplikowane i niewydajne.
• opakować ten obiekt za pomocą dynamicznego proxy (CGLIB) i przechwytywać każdy setter.
  Trochę niewydajne.

Jak byście sobie z problemem tego typu?

Pozdrawiam.

Są do tego gotowce. Audit log czy jako tak. Można zapisać kto, co i kiedy zmieniał.

Klasyczny przykład kiedy wyjątkowo AOP moze się przydać, czyli de facto twoja opcja 3. Co do wydajności to bez przesady, to jest "koszt" jednego pośredniego wywołania funkcji, praktycznie niezauważalnly.

Shalom napisał(a):

Klasyczny przykład kiedy wyjątkowo AOP moze się przydać, czyli de facto twoja opcja 3. Co do wydajności to bez przesady, to jest "koszt" jednego pośredniego wywołania funkcji, praktycznie niezauważalnly.

Masz na myśli kompilowane AOP (AspectJ?), na poziomie samej klasy tego obiektu? Nie chodziło mi o koszt wywołania proxy, tylko jego stworzenia. W tym przypadku byłby tworzony za każdym requestem (zapomniałem wspomnieć - mówimy o microservice).

Nie no tworzenie proxy za każdym razem to bez sensu. Tak, chodziło mi o AspectJ albo spring-aop albo cokolwiek co działa "raz a dobrze".