Pozwól mi podzielić się moją opinią.
Najpierw myślę, że twoje pytanie nie ma nic wspólnego z wiosennym zyskiem. Wiosenny rozruch zapewnia tylko wymyślny i lekki sposób na uruchomienie aplikacji i pozwala na łatwiejsze budowanie aplikacji. Ale nadal masz tam swój kontroler odpoczynku i od tego momentu nie różni się on zbytnio od innych aplikacji.
Pytasz więc, czy ma sens utrzymywanie abstrakcji obiektów JSON i przekształcanie ich w obiekty obiektu logiki biznesowej, a następnie przekształcanie ich ponownie w obiekty bazy danych lub wystarczające do utrzymania tylko 2 poziomów i porzuć poziom Json.
Myślę, że odpowiedź brzmi "to zależy".
Po pierwsze, generalnie obecnie trend stanowi uproszczenie. Może więc wystarczy, aby utrzymać tylko 1 poziom obiektów.
Istnieje wiele zalet takiego podejścia:
- Oczywiście mniej kodu do utrzymania
- szybkości rozwoju i testowania (POJOs powinny być sprawdzane, konwertery powinny być badane i tak dalej)
- Prędkość wykonania - nie trzeba marnować czasu procesora na konwersję. Rodzaj oczywistej implikacji.
- Mniej oczywiste: zużycie pamięci. Powiedzmy, że pracujesz z dużą ilością danych zwróconych przez Twoje DAO. Powiedzmy, że zajmuje to 10 MB pamięci (tylko ze względu na przykład). Teraz, jeśli zaczniesz konwertować, na podmioty gospodarcze, wydasz kolejne 10 MB, a teraz, jeśli jego obiekt JSON jest w obiektywie, jego znowu 10 MB. Chodzi o to, że wszystkie te obiekty mogą współistnieć w pamięci jednocześnie. Oczywiście GC prawdopodobnie zaopiekuje się nimi, jeśli wszystko dobrze zaimplementujesz, ale to już inna historia.
Istnieje jednak jedna wada takiego uproszczenia.
Jednym słowem chciałbym nazwać Zaangażowanie
Istnieją trzy typy interfejsów API w aplikacji.
Interfejs API, z którym jesteś zaangażowany na poziomie usługi sieciowej - struktura JSon. Są szanse, że różni klienci (niekoniecznie korzystający z JVM) działają przeciwko usłudze sieci Web i zużywają dane. Tak naprawdę oczekują od ciebie dostarczenia obiektów JSon o danej strukturze.
Interfejs API Twojej firmy. Jeśli twoja warstwa logiki biznesowej jest dość skomplikowana, prawdopodobnie masz cały zespół, który rozwija tę logikę. Zwykle pracujesz na poziomie interfejsów API między zespołami.
Poziom DAO - w rzeczywistości ta sama historia, co logika biznesowa.
Co się stanie, jeśli np. Zmienisz interfejs API na jednym poziomie? Czy to oznacza, że wszystkie poziomy zostaną zerwane?
Przykład
Powiedzmy, że nie utrzymują poziom "json". W takim przypadku, jeśli zmienimy API na poziomie Business Logic, JSON również zmieni się automatycznie. Wszystkie pozostałe frameworki z radością skonwertują obiekt dla nas i istnieje duże prawdopodobieństwo, że użytkownik otrzyma inne dane.
Innym przykładem
Powiedzmy, twoja warstwa BL zapewnia podmiot osoba, która wygląda tak:
class Person {
String firstName;
String lastName;
List<Language> languages;
}
class Language {
...
}
Teraz, powiedzmy, że masz interfejs, który zużywa swoje usługi REST, który dostarcza lista osób na żądanie. Co jeśli w interfejsie użytkownika są 2 różne strony. Jeden, który pokazuje tylko osoby (w tym przypadku nie ma sensu dostarczanie listy języków, którymi posługuje się dana osoba). Na drugiej stronie jednak chcesz uzyskać pełną informację.
W efekcie ujawnisz 2 serwisy internetowe lub skomplikujesz istniejący za pomocą niektórych parametrów (im więcej takich par, tym mniej przypomina reszty :)) Może rozdzielenie trochę tu pomoże? Nie wiem
Dolna linia. Powiedziałbym, że tak długo, jak można żyć bez takiego oddzielenia - zrób to. Może działać nawet w przypadku dużych projektów. I oczywiście może działać w przypadku małych lub średnich projektów.
Jeśli zmagasz się z naprawami i masz wrażenie, że taka separacja rozwiąże problemy - zrób separację.
Mam nadzieję, że pomaga to zrozumieć konsekwencje i wybrali dla Ciebie to, co działa