Spring - komunikacja z kontrolerem, przesyłanie i odbieranie danych

0

Cześć, mam kilka prostych dla was pytań, które jednak mnie nurtują ;)
Z góry przepraszam, za niski poziom pytań, ale dla mnie takie banalne/banalnie ułożone pytania i odpowiedzi rozwiewają wątpliwości.

  1. Co powinno się zwracać w kontrolerze?
    Stringa, ModelAndView czy coś innego? od czego to zależy co zwracać? mam na myśli:
 
@RequestMapping(value = "/test", method = RequestMethod.POST)
	public String personController(@ModelAttribute("person") Person person, Model model){

		personService.addPerson(person);

		return "test"; 

	}

czy

 
@RequestMapping(value = "/test", method = RequestMethod.POST)
	public ModelAndView personController(@ModelAttribute("person") Person person){

		personService.addPerson(person);
ModelAndView model=new ModelAndView("test");

		return model;

	}

Ogólnie teraz, jako parametr przyjmuje się Model, a jako widok zwraca Stringa, to prawda i tak powinienem postępować?

  1. Co powinienem odbierać w kontrolerze? Jeśli wiem, że dane które będę przetwarzał to dajmy na to dwa stringi, to powinienem
    zrobić coś takiego? public String myController(String temp, String temp2) to chyba zła praktyka?
    3.Czy jeśli jako parametr mam @ModelAttribute("person") Person person, to on automatycznie przesyła mi odebraną wartość do przekierowywanej strony? tj wysyłam person z home.jsp to już ręcznie nie muszę przesyłać tego do następnej strony, np example.jsp?
    4.Dobrze rozumiem, że w kontrolerach odbywa się cała obsługa? Tzn tutaj bez obaw mogę wywoływać różne metody innych klas itp? i jeśli potrzebuje to tworzyć obiekty? Czy to trzeba przekierować gdzieś jeszcze dalej?
    Tzn np potrzebuję sprawdzić czy odebrane dane są poprawne, to tutaj wywołuje metodę sprawdzającą te dane, tak?
    Chce dodać coś do bazy to też? itp..
  2. Jeśli chcę coś dodatkowo przesłać, to jak to robić? model.(attributeName, attributeValue)? to dobra, metoda do tego, tak?
  3. Czy jeszcze się używa HttpServletRequest request, HttpServletResponse response jako argumentów? Czy to przestarzałe? Dlaczego tak/nie?

/*** pytanie z innej beczki
7. Ok rozumiem, że Spring super i w ogóle.. ale co stworzę za pomocą Springa i ogólnie webowej javy jeśli mogę to tak nazwać, czego nie stworzę za pomocą webowych "języków", mam na myśli JavaScript, PHP, CSS, html5 itd itd..
tzn z użyciem Springa normanie tworzy się strony? (tzn wiem, że spring do back-endu itp) ale czy firmy tworzą coś innego? Jakieś przykłady? :) Może proste i głupie pytanie, ale fajnie jakby mi ktoś wytłumaczył ;)

Mam nadzieję, że wszystko w miarę opisałem o co mi chodzi.
Z góry dzięki za wszystkie odpowiedzi.
Pozdrawiam

2
springer napisał(a):

Cześć, mam kilka prostych dla was pytań, które jednak mnie nurtują ;)
Z góry przepraszam, za niski poziom pytań, ale dla mnie takie banalne/banalnie ułożone pytania i odpowiedzi rozwiewają wątpliwości.

  1. Co powinno się zwracać w kontrolerze?
    Stringa, ModelAndView czy coś innego? od czego to zależy co zwracać? mam na myśli:
 
@RequestMapping(value = "/test", method = RequestMethod.POST)
	public String personController(@ModelAttribute("person") Person person, Model model){

		personService.addPerson(person);

		return "test"; 

	}

czy

 
@RequestMapping(value = "/test", method = RequestMethod.POST)
	public ModelAndView personController(@ModelAttribute("person") Person person){

		personService.addPerson(person);
ModelAndView model=new ModelAndView("test");

		return model;

	}

Ogólnie teraz, jako parametr przyjmuje się Model, a jako widok zwraca Stringa, to prawda i tak powinienem postępować?

Zależy. Ogólnie zwracanie ModelAndView pozwala na umieszczenie dodatkowych informacji w zwracanej odpowiedzi. Np. masz jakiś serwis, który coś oblicza i tego rezultaty chcesz zwrócić klientowi. Wtedy możesz taki obiekt dołączyć do zwracanego modelu.
Masz to dobrze opisane tutaj - http://stackoverflow.com/questions/7175509/which-is-better-return-modelandview-or-string-on-spring3-controller
Radzę Ci też zapoznać się z czymś takim, jak serwisy REST'owe - wtedy działasz tylko na czystych obiektach. Tj. przyjmujesz dane od klienta w formie obiektów i zwracasz obiekty.
Generalnie, to co zaprezentowałeś wyżej wykorzystuje się głównie do zwracania danych dla statycznych JSP'ów, co jest już trochę prehistoryczne.

  1. Co powinienem odbierać w kontrolerze? Jeśli wiem, że dane które będę przetwarzał to dajmy na to dwa stringi, to powinienem
    zrobić coś takiego? public String myController(String temp, String temp2) to chyba zła praktyka?

Możesz to odbierać jak chcesz. Jako @PathVariable, @RequestParam czy obiekt @RequestBody. Wszystko zależy od tego ile tego jest, do czego chcesz to wykorzystać i co będzie najlepsze w danym przypadku. Nie ma na to jednolitej odpowiedzi.

3.Czy jeśli jako parametr mam @ModelAttribute("person") Person person, to on automatycznie przesyła mi odebraną wartość do przekierowywanej strony? tj wysyłam person z home.jsp to już ręcznie nie muszę przesyłać tego do następnej strony, np example.jsp?

Przesyłasz obiekt typu Person i działasz sobie na tym obiekcie. Nie ma tu żadnej filozofii. To co zrobisz z tymi danymi i jaką zwrócisz odpowiedź klientowi (w tym przypadku konkretny .jsp) zależy tylko od Ciebie. Możesz te dane, które otrzymałeś w tym obiekcie przekierować na inną stronę.

4.Dobrze rozumiem, że w kontrolerach odbywa się cała obsługa? Tzn tutaj bez obaw mogę wywoływać różne metody innych klas itp? i jeśli potrzebuje to tworzyć obiekty? Czy to trzeba przekierować gdzieś jeszcze dalej?
Tzn np potrzebuję sprawdzić czy odebrane dane są poprawne, to tutaj wywołuje metodę sprawdzającą te dane, tak?
Chce dodać coś do bazy to też? itp..

Głównie dobrą praktyką w kontolerach jest to, zeby tylko odbierały żądania i zwracały odpowiedzi. Cała logika biznesowa, interakcje z bazą danych powinny się odbywać w niższych warstwach. Warstwa kontrolerów jest pierwsza, potem te dane lecą najczęściej do odpowiednich serwisów, te komunikują się z repozytoriami DAO, które zaś zapisują/odczytują dane do/z bazy. Oczywiście ilość warstw zależy od skali wielkości danej aplikacji. Jak aplikacja jest małą i nie ma praktycznie logiki, to raczej nie ma sensu się bawić w taką architekturę. Ale kiedy aplikacja jest duża i ma wiele zadań, wtedy należy taką architekturę dobrze przeanalizować.
Polecam poczytać http://www.mytechnotes.biz/2012/09/spring-mvc-service-dao-persistence.html

  1. Jeśli chcę coś dodatkowo przesłać, to jak to robić? model.(attributeName, attributeValue)? to dobra, metoda do tego, tak?

Nie rozumiem. Co znaczy u Ciebie "coś dodatkowo"? Wszystko możesz przesłać na różne sposoby (trochę o nich wspomniałem wcześniej).

  1. Czy jeszcze się używa HttpServletRequest request, HttpServletResponse response jako argumentów? Czy to przestarzałe? Dlaczego tak/nie?

Rzadko, zależy od aplikacji, tego co robi i sensu używania. Ogólnie Spring sam w sobie to obsługuje. Dlatego wszelkie requesty oznaczane są jako @RequestMapping, a odpowiedzi jako @ResponseBody/@RestController. Radzę poczytać o tym wszystkim, bo bez tego ani rusz. Ogólnie zwykłych serwletów się już nie pisze, frameworki zastąpiły tą robotę

  1. Ok rozumiem, że Spring super i w ogóle.. ale co stworzę za pomocą Springa i ogólnie webowej javy jeśli mogę to tak nazwać, czego nie stworzę za pomocą webowych "języków", mam na myśli JavaScript, PHP, CSS, html5 itd itd..
    tzn z użyciem Springa normanie tworzy się strony? (tzn wiem, że spring do back-endu itp) ale czy firmy tworzą coś innego? Jakieś przykłady? :) Może proste i głupie pytanie, ale fajnie jakby mi ktoś wytłumaczył ;)

Spring to kombajn. Potężne narzędzie z mnóstwem modułów. Oczywiście nie wykorzystuje się wszystkich naraz, tylko dostosowuje się to co potrzeba. Spring to backend, to nie ma nic wspólnego z JS, CSS, HTML. Front jest frontem, a reszta to "mózg" siedzący na serwerze.
Wiele firm tworzy aplikacje webowe z wykorzystaniem Springa, technologii bazodanowych i technologii frontendowych. Spring to tylko jakiś jeden element wszystkich technologii, z których można budować aplikacje.
Tworzenie stron internetowych to jeszcze inna bajka - zależy o co Ci dokładnie chodzi. Dla mnie to tylko HTML, CSS i czasem JS. Nic więcej. Konkretne aplikacje już mają jakąś logikę biznesową i korzystają z wielu zasobów. Wtedy sam front nie wystarcza i trzeba się brać za tworzenie backendu z wykorzystaniem jakichś narzędzi.

0

Dzięki wielkie! :)
O taką odpowiedź mi chodziło! :)

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