MVC(Spring i Swing) - standardowy podział paczek.

0

Witam,
Dopiero zaczynam przygodę z programowaniem w języku JAVA, ale mam kilka pytań odnośnie wzorca MVC(architektury).
Na jakie paczki podzielić projekty w Swingu i Springu?
Doszedłem do:
Spring:
- com.xxx.Dao: interfejsy oraz menagery(dao)
- com.xxx.Enity : encje(sety + gety), modele hibernate
- com.xxx.Controller: kontrolery i akcje
- com.xxx.Validator : walidatory
- com.xxx.Service: serwisy

Swing:
    - com.xxx. - i tu mam duży problem. Wiem że powinno to się dzielić na modele i ui, ale każdy ma jakieś specjalne nazwy oraz metody, same modele dzielą się na dodatkowe kategorie ale jak to podzielić względem paczek.

Proszę o pomoc i PROSZĘ NIE DAWAĆ LINKÓW do obszernych tematów i tak już jestem zmęczony próbą ogarnięcia tego.
Najlepszą pomocą byłyby wasze własne podziały z krótkim opisem.

Pozdrawiam

0

W Swingu nie ma jednoznacznego podziału między modelem, a kontrolerem (co można wyczytać nawet w tutku). Dlatego jeżeli nie będzie to duże, to możesz wrzucić wszystko do jednego pakietu np. com.xxx.swing. Jeżeli będzie tego więcej, to możesz wydzielić np. com.swing.view dla klas widoku, a jeżeli jeszcze więcej, to zgodnie ze strukturą tego co budujesz - wtedy musisz przemyśleć jaka struktura będzie najwygodniejsza z punktu widzenia dostępu i niezbyt dużej głębokości pakietów.

0
Olamagato napisał(a)

W Swingu nie ma jednoznacznego podziału między modelem, a kontrolerem (co można wyczytać nawet w tutku). Dlatego jeżeli nie będzie to duże, to możesz wrzucić wszystko do jednego pakietu np. com.xxx.swing. Jeżeli będzie tego więcej, to możesz wydzielić np. com.swing.view dla klas widoku, a jeżeli jeszcze więcej, to zgodnie ze strukturą tego co budujesz - wtedy musisz przemyśleć jaka struktura będzie najwygodniejsza z punktu widzenia dostępu i niezbyt dużej głębokości pakietów.

Fajnie, ale powiedzmy mam gigantyczne 15 formularzy każdy inny, łączą się one z bazą itd. Jak wszystko wrzucę do jednego czy rozdzielę w podstawowy sposób to powstanie bubel - dodatkowo brak możliwości rozwoju. A jak jest z rozdzielaniem paczek w przypadku MVC, a właściwie M - UI(model i ui kontener)?

0

Wydaje mi się, że mógłbyś w takim wypadku utworzyć dwa podpakiety np. com.xxx.swing.mc i com.xx.swing.v a wewnątrz nich umieścić właściwe podpakiety dla każdego formularza osobno - w przypadku gdy mają być zupełnie niezależne od siebie (i razem gdy będą współzależne). Struktura pakietowa jest dość niezależna od projektów, więc można też część struktury pakietów umieścić w jednostkach osobno kompilowanych. Do sklejenia kodu obu podpakietów (.mc i .v) używałbym kodu wrzuconego do com.xxx.swing i jako ogólną zasadę, że swingowy kod z pakietu skorzysta głównie ze swingowego api jego podpakietów (czyli ze swojego poddrzewka) i nie korzysta z innych "gałązek". Tego jednak nie da się wymusić za pomocą języka (wszystkie pakiety składają się na ten sam interfejs globalny, stąd też propozycje pojawienia się w Javie super-pakietów), można to jednak zewnętrznie wymusić (np. przy pomocy adnotacji) i łatwo ręcznie sprawdzić widząc od razu importy spoza "swojego drzewka".

0
Olamagato napisał(a)

Wydaje mi się, że mógłbyś w takim wypadku utworzyć dwa podpakiety np. com.xxx.swing.mc i com.xx.swing.v a wewnątrz nich umieścić właściwe podpakiety dla każdego formularza osobno - w przypadku gdy mają być zupełnie niezależne od siebie (i razem gdy będą współzależne). Struktura pakietowa jest dość niezależna od projektów, więc można też część struktury pakietów umieścić w jednostkach osobno kompilowanych. Do sklejenia kodu obu podpakietów (.mc i .v) używałbym kodu wrzuconego do com.xxx.swing i jako ogólną zasadę, że swingowy kod z pakietu skorzysta głównie ze swingowego api jego podpakietów (czyli ze swojego poddrzewka) i nie korzysta z innych "gałązek". Tego jednak nie da się wymusić za pomocą języka (wszystkie pakiety składają się na ten sam interfejs globalny, stąd też propozycje pojawienia się w Javie super-pakietów), można to jednak zewnętrznie wymusić (np. przy pomocy adnotacji) i łatwo ręcznie sprawdzić widząc od razu importy spoza "swojego drzewka".

A co w przypadku kiedy projekt przechodzi z rąk do rąk, programiści mogą mieć problem z ogarnięciem projektu jeżeli będzie on w ten sposób tworzony. Nie ma jakiegoś standardu, powiedzmy jak w przypadku php i mvc? Nie chodzi mi tu o wymyślanie jakiejś struktury opartej o moduły, ale o sprawdzony i przetestowany schemat, który sprawdzi się w większości przypadków. Wiadomo, że istnieją przypadki w których trzeba podejść indywidualnie. Jestem początkującym programistą, który chce po prostu oprzeć się o czyjś schemat, a nie tworzyć coś nowego i nie do końca zrozumiałego.Wiem np. że swing ma modele komponentów ale nie wiem jak się to ma do listenerów i innych dziwolągów i jak to podzielić.

0

Niech ktoś się wypowie.. .

0

Propozycja może trochę inna, ale sprawdzająca się. Zamiast MVC użyć w części swingowej MVP (http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter).

com.xxx.swing.model - klasy z "gołym" modelem do wyświetlania po stronie UI, czyli tylko nośnik danych - DTO.
com.xxx.swing.presenter - klasy reprezentujące UI.
com.xxx.swing.view - action listenery i tego typu duperele delegujące zachowania do kontrolerów springowych.

Ogólnie flow w takiej aplikacji będzie mniej więcej taki:

Swing View - wciskamy button > pobranie obiektów DTO z UI i mapowanie ich na Model Springa > wywołanie kontrolera springowego > magia po stronie springa > spring zwraca ModelAndView do Swing View > mapowanie Model na DTO z UI i wybranie prezentera > Prezenter otrzymuje DTO i aktualizuje kontrolki.

Przy czym Swing View powinno działać na zasadzie routera czyli mieć mapę prezenterów i na podstawie informacji z ModelAndView Springa wybierać odpowiedni prezenter. W web-mvc jest to ukryte w DispatcherServlet tu trzeba wyrzeźbić samemu.

0
Koziołek napisał(a)

Propozycja może trochę inna, ale sprawdzająca się. Zamiast MVC użyć w części swingowej MVP (http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter).

com.xxx.swing.model - klasy z "gołym" modelem do wyświetlania po stronie UI, czyli tylko nośnik danych - DTO.
com.xxx.swing.presenter - klasy reprezentujące UI.
com.xxx.swing.view - action listenery i tego typu duperele delegujące zachowania do kontrolerów springowych.

Ogólnie flow w takiej aplikacji będzie mniej więcej taki:

Swing View - wciskamy button > pobranie obiektów DTO z UI i mapowanie ich na Model Springa > wywołanie kontrolera springowego > magia po stronie springa > spring zwraca ModelAndView do Swing View > mapowanie Model na DTO z UI i wybranie prezentera > Prezenter otrzymuje DTO i aktualizuje kontrolki.

Przy czym Swing View powinno działać na zasadzie routera czyli mieć mapę prezenterów i na podstawie informacji z ModelAndView Springa wybierać odpowiedni prezenter. W web-mvc jest to ukryte w DispatcherServlet tu trzeba wyrzeźbić samemu.

Masz może jakiś przykład? Wiem google ale google znajduje MVC a nie MVP.Bo jestem początkującym programistą.

0

http://www.google.pl/search?q=MVP+pattern&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:pl:official&client=firefox-a > trochę będzie w Googlu.

Poza tym tutoriale do GWT, bo tam jest MVP i do samego Swinga, bo to też MVP.

1 użytkowników online, w tym zalogowanych: 0, gości: 1