J2EE: Как я могу лучше структурировать свои сервлеты? - PullRequest
Новая
       2

J2EE: Как я могу лучше структурировать свои сервлеты?

1 голос
/ 02 июня 2011

Веб-приложение, которое я сейчас создаю, соответствует MVC. Я структурировал сервлеты таким образом, чтобы каждый из них обрабатывал связанные действия (поэтому один сервлет может отвечать за все действия, связанные с настройкой учетной записи пользователя, а другой может использоваться для переписки пользователя). В настоящее время у меня есть параметр «action», присоединенный ко всем строкам запроса (для GET) и телам запросов (для POSTS), и использую его для определения того, какое действие необходимо выполнить в этих сервлетах «связанных действий».

Другими словами, мой код структурирован примерно так: 

protected void doGet(HttpServletRequest request, HttpServletResponse response)
{
    String action = request.getParameter("action");

    if(action.equals("login"))
    {
        .....
    }
    else if(action.equals("createAccount"))
    {
        ....
    }
    else if(action.equals("changePassword"))
    {
        ....
    }
    ..........
}

Я относительно рано в процессе разработки, и на данный момент я не нахожу никаких проблем с обслуживаемостью, вытекающих из этого проекта. Согласно MVC, все сервлеты вызывают методы моих служебных классов; в них не выполняется никакой реальной работы, за исключением отправки ответов клиенту. Но просматривая SO, я сталкиваюсь с мнением, что даже операторы if-else среднего размера (~ 10 или меньше "elses") являются запахом кода и предполагают, что пользователь не делает "OOP-путь".

Есть ли лучший способ фильтровать типы запросов, поступающих на мои сервлеты? Я хотел бы иметь возможность улучшить поддержку моего приложения, но не желать реализовывать функции ООП только потому, что они ООП (подобно тому, как люди презирают пуристов, которые настаивают на жесткой инкапсуляции, до такой степени, что у них 24 однострочных). добытчики / Сеттера).

Ответы [ 3 ]

2 голосов
/ 02 июня 2011

Помимо использования инфраструктуры, как предложил Джонатан, вы также можете разбить функциональность на несколько сервлетов. Вам придется решить, где находится логический разрыв, но ваши URL-адреса будут напоминать нечто похожее на REST API.

Пример URL-адреса будет http://myapp.com/create_account или http://myapp.com/login

Каждый из URL может быть сопоставлен с отдельными сервлетами.

2 голосов
/ 02 июня 2011

Рассматривали ли вы использование предварительно запеченной инфраструктуры MVC, такой как Apache Struts , Spring или Google SiteBricks ?Все это замечательно и может значительно снизить нагрузку на ваш код.Я настоятельно рекомендую пойти по этому пути.Вы избавите себя от некоторых головных болей и кошмаров, связанных с обслуживанием, по мере того, как катитесь на своих собственных.

Если вы не можете по какой-то причине, то, честно говоря, я не думаю, что с тем, что вы сделали, обязательно есть проблема.Кажется понятным и ремонтопригодным.По сути, то, что вы сделали, очень похоже на то, как микро-фреймворки, такие как Sinatra , работают для базовой обработки URL-адресов, хотя они и делают это с хорошим синтаксическим сахаром.

1 голос
/ 03 июня 2011

Если вы просто хотите избежать запаха кода с помощью больших операторов if и быть немного больше ОО, вы можете попробовать использовать реализацию в стиле отражения, если вы можете заставить свои служебные классы реализовать тот же интерфейс. По сути, значение параметра action будет представлять собой фактическое имя класса (или его часть, с соответствующими значениями, добавленными или добавленными). 

String action = request.getParameter("action");
Class clazz = Class.forName(action);
UtilityInterface utilityObj = (UtilityInterface)clazz.newInstance();
...