2016-07-20 3 views
0

Я работаю над приложением Java EE, и я пытаюсь реализовать его после шаблона MVC. Я не использую никаких фреймворков (например, Spring) для реализации структуры MVC. Я просто пишу свои собственные модели, представления и контроллеры/с.MVC-шаблон, один или несколько контроллеров/сервлетов?

Я начал внедрять свое приложение, используя разные сервлеты для каждой функциональности (например, LoginServlet, RegisterServlet), но я заметил, что многие говорят, что одного контроллера (сервлета) достаточно для обработки всех функциональных возможностей приложения. Однако я не понимаю, как это могло произойти, не получив в результате беспорядочный код. То, как я думаю, это наличие одного сервлета/контроллера с несколькими операторами if/else, чтобы проверить, откуда приходит запрос. Результатом будет огромный метод doPost или doGet с множеством операторов if/else, который звучит как плохая идея.

Подводя итог, хорошая или плохая идея иметь другой сервлет для каждой функциональности приложения, и если это плохо, как я могу достичь того же, используя один сервлет и не создавая огромных методов?

+0

Почему вы хотите, чтобы заново изобретать колесо? Любая хорошая причина для отказа от использования каких-либо фреймворков? –

+2

@ Sundararaj Потому что, может быть, он хочет научиться правильно делать все? Если он всегда зависит от структуры, чтобы заниматься историей, он никогда не научится правильно. –

+0

@ Александр, это может быть веской причиной. –

ответ

1

Это зависит от модели, которую вы используете. Мое предложение - начать читать образцы дизайна. Одним из примеров того, как вы можете иметь один контроллер, является шаблон «Front Controller». Знаменитый «распорки» является примером его использования: https://en.wikipedia.org/wiki/Front_controller

Вот ссылка с примером реализации:

http://www.oracle.com/technetwork/java/frontcontroller-135648.html

-1

Хорошие и плохие субъективны.

Обычно используется один DispatcherServlet (он же сервлет Суперконтроллера), который будет принимать HTTP-запросы и направлять код на соответствующий обработчик с учетом URL-адреса.

Я думаю, что REST и микросервисы идут еще на один шаг и раскрывают функциональность как несколько конечных точек HTTP.

Это еще один случай Java EE, или ваша интерпретация его, находясь за раз.

Я бы сделал это с помощью Spring, используя несколько конечных точек REST.

+0

Он не использует никаких фреймворков, и один взломанный сервлет поможет ему. –

+0

Я понимаю это. Я указал примеры того, как это делалось раньше другими. Вы можете делать REST и микросервисы без рамки. Если вы проголосовали за это, я бы хотел, чтобы вы вернули его или опубликовали что-то помимо комментария, чтобы мы могли узнать, какой уровень знаний вы планируете вывести на вечеринку. «Взорвался сервлет»? Пожалуйста, объясни. – duffymo

+0

@duffymo является правильным для части микросервиса, хотя я не уверен, что он был серьезен или шутил, когда он упоминал REST вручную :) Но да, REST может быть закодирован вручную, а также при условии соблюдения основных принципов RESTful. –

-1

Нет, вы должны разделить свои сервисы логичным способом. На самом деле вы должны разделить свою упаковку на большие логические подразделения. Для сервлетов для примера AuthenticationServet для обработки всех потоков аутентификации, RegistrationServlet, EShopServlet и т.д.

Пакеты

com.myapp.servlets.* 
com.myapp.models.jpa* 
com.myapp.models.(something)* 
com.myapp.services.* 
+0

Вопрос о no.of сервлетов, а не пакетов. –

+0

@SundararajGovindasamy Вы должны прочитать мой ответ еще раз перед голосованием. Мой ответ говорит ему, как назвать и организовать сервлеты, и я также * SUGGESTING * сделать то же самое с пакетами. –

+0

Я прокомментировал ваш ответ, но зато отрицал? это не я. –

Смежные вопросы