Wzorce projektowe aplikacje internetowe [zamknięte]

Trochę przyzwoita aplikacja internetowa składa się z mieszanki wzorców projektowych. Wspomnę tylko o tych najważniejszych.

Model View Controller pattern

Podstawowy (architektoniczny) wzorzec projektowy, którego chcesz użyć, to wzorzec model-widok-kontroler. Kontroler ma być reprezentowany przez Servlet, który bezpośrednio tworzy/używa określonego modelu i widoku na podstawie żądania. Model ma być reprezentowane przez klasy Javabean. Jest to często dalej dzielone w model biznesowy , który zawiera działania (zachowanie) i model danych , który zawiera dane (informacje). Widok ma być reprezentowany przez pliki JSP, które mają bezpośredni dostęp do danych () Model by EL (Expression Language).

Następnie, istnieją różnice w zależności od tego, jak działania i zdarzenia są obsługiwane. Popularne są:

• Request (action) based MVC: jest to najprostszy do zaimplementowania. Biznes () Model działa bezpośrednio z obiektami HttpServletRequest i HttpServletResponse. Musisz zebrać, przekonwertować i zweryfikować parametry żądania (głównie) samodzielnie. Widok może być reprezentowany przez zwykły waniliowy HTML / CSS / JS i nie zachowuje stanu między żądaniami. Tak m.in. Spring MVC, Rozpórki I paski działa.

• MVC oparte na komponentach : jest to trudniejsze do wdrożenia. Ale kończy się prostszy model i widok, w którym wszystkie "surowe" API Servlet jest abstrakcyjny całkowicie. Nie powinieneś mieć potrzeby samodzielnego gromadzenia, konwersji i walidacji parametrów żądania. Kontroler wykonuje to zadanie i ustawia zebrane, przekonwertowane i zweryfikowane parametry żądania w modelu . Wszystko, co musisz zrobić, to zdefiniować metody działania, które działają bezpośrednio z właściwościami modelu. Widok jest reprezentowany przez "komponenty" w znacznikach JSP lub elementach XML, które z kolei generują HTML/CSS / JS. Stan widoku dla kolejnych żądań jest utrzymywany w sesji. Jest to szczególnie przydatne w przypadku konwersji po stronie serwera,walidacji i zmian wartości. Tak m.in. JSF, Wicket i Graj!Działa.

Na marginesie, hobby wokół z domowy Framework MVC jest bardzo miłym ćwiczeniem edukacyjnym i polecam go tak długo, jak długo przechowujesz go do celów osobistych/prywatnych. Ale gdy przejdziesz do profesjonalizmu, zdecydowanie zaleca się wybranie istniejących ram, a nie wymyślanie własnych. Uczenie się istniejących i dobrze rozwiniętych frameworków zajmuje w dłuższej perspektywie mniej czasu niż samodzielne opracowanie i utrzymanie solidnych frameworków.

W poniższym szczegółowym wyjaśnieniu ograniczę się do request based MVC, ponieważ to łatwiejsze do wdrożenia.

Wzór kontrolera przedniego (wzór mediatora )

Pierwszy, Kontroler część powinna zaimplementować przedni kontroler wzór (który jest wyspecjalizowanym rodzajem mediator wzór). Powinien on składać się tylko z jednego serwletu, który zapewnia scentralizowany punkt wejścia dla wszystkich żądań. Powinien on stworzyć model w oparciu o informacje dostępne w zapytaniu, takie jak pathinfo lub servletpath, metoda i / lub określone parametry. Model biznesowy nazywa się Action poniżej HttpServlet przykład.

protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    try {
        Action action = ActionFactory.getAction(request);
        String view = action.execute(request, response);

        if (view.equals(request.getPathInfo().substring(1)) {
            request.getRequestDispatcher("/WEB-INF/" + view + ".jsp").forward(request, response);
        }
        else {
            response.sendRedirect(view); // We'd like to fire redirect in case of a view change as result of the action (PRG pattern).
        }
    }
    catch (Exception e) {
        throw new ServletException("Executing action failed.", e);
    }
}

Wykonanie akcji powinno zwrócić jakiś identyfikator, aby zlokalizować widok. Najprościej byłoby użyć go jako nazwy pliku JSP. Mapować ten servlet na konkretny url-pattern W web.xml, np. /pages/*, *.do lub nawet po prostu *.html.

W przypadku prefix-patterns jak na przykład /pages/* można wtedy wywołać URL ' a jak http://example.com/pages/register, http://example.com/pages/login , itp. i zapewniają /WEB-INF/register.jsp, /WEB-INF/login.jsp z odpowiednimi akcjami GET I POST. Części register, login, itp są wówczas dostępne przez request.getPathInfo() jak w powyższym przykładzie.

Gdy używasz sufiksów-wzorców takich jak *.do, *.html, itd, następnie można wywołać URL jest jak http://example.com/register.do, http://example.com/login.do , etc i należy zmienić kod przykłady w tej odpowiedzi (również ActionFactory), aby wyodrębnić register i login części przez request.getServletPath() zamiast tego.

Wzór strategii

Action powinny być zgodne ze schematem strategii . Musi być zdefiniowany jako typ abstrakcyjny / interfejs, który powinien wykonywać pracę w oparciu o przekazane w argumenty metody abstrakcyjnej (jest to różnica z wzorcem poleceń , w którym Typ abstrakcyjny / interfejs powinien wykonywać pracę na podstawie argumentów, które zostały przekazane podczas tworzenia implementacji).

public interface Action {
    public String execute(HttpServletRequest request, HttpServletResponse response) throws Exception;
}

Możesz chcieć uszczegółowić Exception za pomocą wyjątku niestandardowego, takiego jak ActionException. To tylko podstawowy przykład, reszta zależy od Ciebie.

Oto przykład LoginAction, który (jak sama nazwa mówi) loguje się do użytkownika. Sam model User jest z kolei modelem danych. widok {[59] } jest świadomy obecności User.

public class LoginAction implements Action {

    public String execute(HttpServletRequest request, HttpServletResponse response) throws Exception {
        String username = request.getParameter("username");
        String password = request.getParameter("password");
        User user = userDAO.find(username, password);

        if (user != null) {
            request.getSession().setAttribute("user", user); // Login user.
            return "home"; // Redirect to home page.
        }
        else {
            request.setAttribute("error", "Unknown username/password. Please retry."); // Store error message in request scope.
            return "login"; // Go back to redisplay login form with error.
        }
    }

}

Wzór metody Fabrycznej

ActionFactory powinny być zgodne ze wzorem metody Fabrycznej . Zasadniczo powinien on zapewniać metodę kreacyjną, która zwraca konkretną implementację typu abstrakcyjnego / interfejsu. W takim przypadku powinien on zwrócić implementację interfejsu Action w oparciu o informacje dostarczone przez żądanie. Na przykład, metoda i pathinfo (pathinfo jest częścią po kontekście i ścieżka servleta w adresie URL żądania, z wyłączeniem ciągu zapytania).

public static Action getAction(HttpServletRequest request) {
    return actions.get(request.getMethod() + request.getPathInfo());
}

actions z kolei powinna być jakaś statyczna / aplikacyjna Map<String, Action>, która przechowuje wszystkie znane akcje. Od Ciebie zależy, jak wypełnić tę mapę. Hardcoding:

actions.put("POST/register", new RegisterAction());
actions.put("POST/login", new LoginAction());
actions.put("GET/logout", new LogoutAction());
// ...

for (Entry entry : configuration) {
    actions.put(entry.getKey(), Class.forName(entry.getValue()).newInstance());
}

Lub dynamicznie na podstawie skanowania w classpath dla klas implementujących określony interfejs i / lub adnotację: (pseudo)

for (ClassFile classFile : classpath) {
    if (classFile.isInstanceOf(Action.class)) {
       actions.put(classFile.getAnnotation("mapping"), classFile.newInstance());
    }
}

Należy pamiętać, aby utworzyć "nic nie robić" Action W przypadku, gdy nie ma mapowania. Niech na przykład zwróci bezpośrednio request.getPathInfo().substring(1) wtedy.

Inne wzory

To były ważne wzory do tej pory.

Aby przejść o krok dalej, możesz użyć wzór elewacji do utworzenia klasy Context, która z kolei owija obiekty request I response i oferuje kilka wygodnych metod delegowania do obiektów request I response i przekazać to jako argument do metody Action#execute(). Dodaje to dodatkową warstwę abstrakcyjną, aby ukryć surowe API serwletów. Wtedy powinieneś skończyć z zero import javax.servlet.* deklaracje w każdym Action wdrożeniu. W sensie JSF, to jest to, co FacesContext oraz ExternalContext zajęcia się kończą. Konkretny przykład można znaleźć w tej odpowiedzi .

Potem jest wzorzec stanu Dla Przypadku, w którym chcesz dodać dodatkowy warstwa abstrakcji do podziału zadań gromadzenia parametrów żądania, ich konwersji, walidacji, aktualizacji wartości modelu i wykonywania akcji. W sensie JSF, to jest to, co LifeCycle robi.

Następnie istnieje wzorzec złożony Dla Przypadku, w którym chcesz utworzyć widok oparty na komponentach, który może być dołączony do modelu i którego zachowanie zależy od stanu cyklu życia opartego na żądaniach. W sensie JSF, to jest to, co UIComponent reprezentować.

W ten sposób możesz ewoluować bit po bitie w kierunku frameworka opartego na komponentach.

Zobacz też:

• przykłady wzorców projektowych GoF w podstawowych bibliotekach Javy
• różnica między Request MVC a Component MVC
• wyświetlanie JDBC ResultSet w HTML na stronie JSP przy użyciu wzorca MVC i DAO
• jakie komponenty są MVC w JSF MVC framework?
• JSF Kontroler, Serwis i DAO