Jedna lub wiele serwletów na aplikację internetową?

Question

Wiem, to zależy od webapp. Ale w normalnym przypadku, co robisz: jeden serwlet, który obsługuje różne strony (jak samodzielna aplikacja ze zmienną zawartością) lub dla każdej strony pojedynczy serwlet.

Weźmy na przykład blog. Jest strona początkowa z najnowszymi wpisami blogów, widok artykułu do wyświetlania jednego wpisu na blogu i archiwum. Czy implementujesz to z trzema różnymi serwletami lub tymi, które wysyłają do funkcji. Co najmniej część elementów jest udostępniana, podobnie jak nagłówki http.

Jakie są twoje doświadczenia, co działa najlepiej?

Answer 1

Zazwyczaj tworzy się serwlet na przypadek użycia. Serwlety działają jak kontrolery dla twojej aplikacji. Kiedy identyfikujesz interakcję z użytkownikiem, zaimplementuj serwlet, aby kontrolować tę interakcję.

To znaczy, jeśli używasz zwykłego serwletu/strony JSP do zbudowania witryny. Jeśli korzystasz z frameworka takiego jak rozpórki, okaże się, że implementują wzorzec kontrolera frontowego i używają pojedynczego serwletu, który otrzymuje wszystkie żądania i przekazuje te żądania do klas działań, które implementują rzeczywistą logikę żądania użytkownika. jest to o wiele trudniejsze, ale jest to dobra praktyka ... to powód, dla którego tak wiele osób korzysta z tych ram.

Krótka odpowiedź brzmi: utworzysz wiele apletów na każdą aplikację internetową, ponieważ każda aplikacja będzie wyświetlać kilka przypadków użycia.

[EDYCJA] Ponowne przeczytanie pytania wydaje się, że używasz terminu witryna do oznaczenia strony lub widoku. Ponownie, zależy to od tego, co dzieje się w tym widoku. Na przykład, aby wyświetlić najnowszy wpis blogu, możesz mieć serwlet, który tworzy listę wpisów z bazy danych do wyświetlenia. Jeśli użytkownik kliknie pozycję, wówczas inny serwlet może pobrać tę pojedynczą pozycję do przeglądania i tak dalej. Przede wszystkim każde działanie jest przypadkiem użycia, a zatem innym serwletem.

Answer 2

Większość frameworków internetowych korzysta z serwletu dyspozytora (np. Spring MVC), który zajmuje się kierowaniem żądań do odpowiednich klas/kontrolerów.

Po uruchomieniu dużej liczby stron, to podejście działa najlepiej, ponieważ masz bardziej przyjazny dla użytkownika sposób (w odniesieniu do web.xml) deklarowania/zarządzania klasą, która obsługuje żądania HTTP i jej adres URL. Przykład (ponownie wiosna mvc):

@Controller 
public class MyController { 
@RequestMapping("/viewPosts") 
public void doViewPosts(HttpRequest r, HttpResponse res) { 
    //... 
} 
} 

Poza tym posiadanie serwletu dyspozytora utrzymuje scentralizowany przepływ kodu.

Answer 3

To zależy.

W moich najnowszych projektach zaimplementowałem pojedynczy serwlet, który przenosi się do kilku obiektów podobnych do serwletów, które są tworzone w trybie wtrysku zależności. Na przykład, mam coś takiego w moim serwletu (pseudo-kod):

for(Handler handler : handlers) { 
    if(handler.handle(request, response)) { 
     return; 
    } 
} 

gdzie Handler jest interfejsem z uchwytem (logicznym wniosek, odpowiedzi) metody. Dostaję moje wózki z pojemnika (np. Wiosna lub coś jeszcze bardziej lekkiego).

Powodem tego jest fakt, że bardzo podoba mi się wstrzyknięcie zależności i trudno jest to osiągnąć w Servletach; i naprawdę nie czuję się jak u siebie w domu z większością frameworków, które zapewniają iniekcję zależną od składnika webowego - lubię prostotę serwletów.

Gdyby nie to, chciałbym pójść z wieloma serwletami, chociaż istnieje kompromis; albo masz ogromny webml xml z wieloma (i wieloma) mapowaniami serwletów lub masz bardzo złożony serwlet (chyba że używasz czegoś podobnego do mojego podejścia d-i).