Struktura warstwy widoku i wymiana danych Spring

Witam,

Niedługo zaczynam implementacje pewnego serwisu internetowego. Serwis będzie posiadał dość duży wachlarz możliwości. Dotychczasowe założenia odnośnie architektury są dość standardowe:

-aplikacja będzie korzystała z frameworka Spring
-model danych (encje JPA/Hibernate)
-warstwa Dao (@Repository)
-warstwa serwisów komunikujaca sie z kontrolerami (transakcje na poziome seriwsow)

Natomiast nie wiem jak postąpić z widokiem. I tu mam pare pytań. (Jakiś czas temu zadawałem podobne pytanie ale rozwiązanie którego użyłem w poprzedniej aplikacji generalnie się nie sprawdziło za dobrze, dlatego czas na coś innego)

Wiadomo standardowym rozwizaniem jest Spring MVC (widok JSP) i z tego w znacznym stopniu chciałbym korzystać, ale..
Bardzo podoba mi się podejscie Single Page App z wykorzystaniem AngularJs-a, możliwość edycji zawartości bez odświeżania. Problem w tym, że moja aplikacja będzie duża i na pewno nie będzie pasowała do tej koncepcji. i teraz pytania,

1. Czy jest sens łączyć te koncepcje? Czyli głównie spring MVC i w zależności od potrzeb AngularJs? To by wymagało implementacji standardowych kontrolerow, plus restowych kontrolerow, bez sensu troche... Jednak używanie samego Angulara daje piękne rozwiązanie wystawianie eleganckich restów i brak problemu z LazyInitializationException, natomiast Spring MVC tu sa problemy, ciągle nie znam dobrego podejścia do komunikacji widoku z modelem, używanie encji skutkuje powyższym Exceptionem natomiast jakiś rozwiązanie np z DTO dubluje kod, może jakieś inne rozwiązanie?
2. Czy lepiej skupić się na jednej koncepcj, czy łączenie ich jest całkiem normalne? Może inne podejście?
3. Chciałbym podzielić apke na moduły, zastanawiam się jak to zrobic najlepiej? Planuje w oddzielnym module zamieścic implementacje widoku i modelu ale nie wiem jak postąpić z dao, serwisami i kontrolerami, w jakim module powinno się to znaleźć? jak połączyć te pakiety zgodnie ze sztuką?
4. Zależy mi na informacji w jaki sposób Wy projektujecie swoje aplikacje w połączeniu se Springiem, jakieś dobre nawyki podejścia?

-warstwa serwisów komunikujaca sie z kontrolerami (transakcje na poziome seriwsow)
nie rozumiem, chyba na odwrót

-warstwa Dao (@Repository)
DAO !=Repository

1. Tutaj zależy od wymagań, masz klientów na IE7 to AngularJS odpada. W spring MVC DTO
2. Mix jest oki. My mamy Spring MVC + koszyk w MarionneteJS + REST'y
3. Znów skupiasz się na technikaliach podziel moduły merytorycznie i zastanów się jak mają się spinać. Czyli masz apke i moduł sprzedaży to teraz powinno się dać taki moduł odłączyć, ale jak to teraz wpływa na aplikację co ginie z widoku, gdzie nie będzie cześci logiki bizneosowej itp
4. Zależy od skali i skompilkowania proste podejście Controller>Service->DAO->ORM wystarcza do prostych rzeczy. W pozostałych robimy Hexa, Ports and Adapters. I podział na logikę aplikacji i beznesową. Chcielibyśmy DDD ale jesteśmy za słabi

0. Single page app to rak i z utęsknieniem czekam aż umrze.
1. Lazy init ex znaczy że nie rozumiesz jak działa jpa, spring czy angular nie mają tu nic do rzeczy. Co też sugeruje że to ładne działanie którym się podniecasz to poważny błąd znany jako n +1 select...

Shalom napisał(a):

0. Single page app to rak i z utęsknieniem czekam aż umrze.

Możesz rozwiniąć swoją wypowiedź ? Jestem młodym programistą i dużo osób właśnie poleca rodzielenie a tu Widzę doświadczony programista "czeka ąż umrze" - dziękuje z góry.

@Szczery

-warstwa serwisów komunikujaca sie z kontrolerami (transakcje na poziome seriwsow)

faktycznie troche nie zrozumiale to napisałem, tak chodzi o komunikacjie kontrolerów z serwisami.

warstwa Dao (@Repository)

@Repository służy do adnotowania klas komunikujacych sie ze źródłem danych, praktycznie robi to samo co @Service i @Component ale daje nam możliwość rozdzielenia warstw aplikacji - tak ja to rozumiem, a co masz na myśli mowiaz ze DAO != Repository?

Mówiąc o Ports and adapters rozumiem, że masz na myśli Hexagonal Architecture? Z podejściem o którym mówisz nie miałem jeszcze do czynienia więc zastanawiam się gdzie jest granica prostej aplikacji :> Możesz coś więcej napisać?

@Shalom

0. Też bym prosił o trochę dokładniejszą wypowiedz dlaczego spa jest złym rozwiązaniem.
1. Tak sie składa, że wiem jak działa jpa i spring i rozwiązanie o ktorym mówiłem "podniecając" się, dobrze zaimplementowane nie spowoduję problemów o których mówimy.

• sądze, że jesteś doświadczonym programistą więc na pewno znasz dobre rozwiązania przy tego typu aplikacjach. Jak możesz to napisz coś konkretnego na ten temat, jakiś sprawdzone sposoby?

@Shalom błagam napisz o tym SPA. albo na komórce albo jak wrócisz z wakacji. to jest !important , bo takich słów nie rzuca się na wiatr!!

mateuszq napisał(a):

Jednak używanie samego Angulara daje piękne rozwiązanie wystawianie eleganckich restów i brak problemu z LazyInitializationException, natomiast Spring MVC tu sa problemy, ciągle nie znam dobrego podejścia do komunikacji widoku z modelem, używanie encji skutkuje powyższym Exceptionem natomiast jakiś rozwiązanie np z DTO dubluje kod, może jakieś inne rozwiązanie?

LOLLLL. nie pisz tak. ten exception to z twojej niewiedzy a nie przez Springa. DTO to standardowe, nie ma nic idealnie zawsze masz trochę boiler codu. DTO jest nice.

Wielkość projektu to rzecz względna dla mnie jeśli zespół 7 osobowy jest w stanie zrobić projekt w rok to to jest projekt mały.

DAO != Repository chodzi o wzorzec. To że spring zaczął oznaczać adnotacją @Repository obiekty typu DAO to jest nadużycie ale po rozmowie z autorami dowiedziałem się, że to zabieg marketingowy trendy DDD

Jeśli chodzi o SPA to uważam, że użycie tego podejścia w 90% jest niezasadne i standardowe podejście server side się lepiej sprawdzi. Później rodzą się problemy z SEO, wydajnością, błędami po stronie klienta, init time itp.

Jednak SPA się rozwija i jest promowane przez spore firmy więc długo pożyje....
Wszystko zależy od wymagań. Zazwyczaj robimy mixa 90% server side + 10% client side