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

Odpowiedz Nowy wątek
primosz67
2011-10-16 22:34
primosz67
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

Pozostało 580 znaków

2011-10-17 09:07

Rejestracja: 11 lat temu

Ostatnio: 1 rok temu

Lokalizacja: Polska, Warszawa

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.


Jeżeli ktoś komuś coś, ewentualnie nikt nikomu nic, to właściwie po co...?

Pozostało 580 znaków

primosz67
2011-10-17 12:10
primosz67
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)?

Pozostało 580 znaków

2011-10-17 12:50

Rejestracja: 11 lat temu

Ostatnio: 1 rok temu

Lokalizacja: Polska, Warszawa

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".


Jeżeli ktoś komuś coś, ewentualnie nikt nikomu nic, to właściwie po co...?

Pozostało 580 znaków

primosz67
2011-10-17 13:51
primosz67
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ć.

Nie znam firmy, której zależałoby na tym aby pojedynczy programista ogarnął całość projektu. :) - Olamagato 2011-10-17 20:35

Pozostało 580 znaków

primosz67
2011-10-20 21:59
primosz67
0

Niech ktoś się wypowie.. .

Pozostało 580 znaków

2011-10-21 09:40

Rejestracja: 12 lat temu

Ostatnio: 16 godzin temu

0

Propozycja może trochę inna, ale sprawdzająca się. Zamiast MVC użyć w części swingowej MVP (http://en.wikipedia.org/wiki/[...]2%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.

Pozostało 580 znaków

primosz67
2011-10-25 10:01
primosz67
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/[...]2%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ą.

Pozostało 580 znaków

2011-10-25 10:03

Rejestracja: 12 lat temu

Ostatnio: 16 godzin temu

0

http://www.google.pl/search?q[...]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.

Pozostało 580 znaków

Odpowiedz

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