MVC дизайн путаницы - PullRequest
Новая
       10

MVC дизайн путаницы

1 голос
/ 09 декабря 2011

Я сейчас работаю на небольшом сайте бронирования.И у этого сайта есть один сервлет с большим блоком if-else с 85 условиями для перенаправления запроса на соответствующий jsp.Этот же сервлет содержит некоторую бизнес-логику.Этот сервлет напрямую вызывает объекты доступа к данным.Эти объекты доступа к данным также имеют некоторую бизнес-логику.Таким образом, бизнес-логика разделяется между сервлетом и DAO.У меня два путаницы.

1) Сервлет - это анти-паттерн.Поэтому я пытаюсь сделать его меньше и разделить его на несколько сервлетов, чтобы каждый сервлет имел какую-то конкретную цель.Мой вопрос должен ли я сделать один сервлет для каждого условия.Это сделало бы 85 различных сервлетов.

2) Сколько слоев я должен иметь между DAO и сервлетами.Я думаю о двух, потому что мне нужно, чтобы один слой преобразовал входные данные, специфичные для веб-интерфейса, в обобщенный запрос.А второй уровень будет обрабатывать обобщенный запрос и при необходимости вызывать DAO.Так что если потом, когда мы решим сделать мобильное приложение.Нам просто нужно сделать один уровень обработки запроса специфичным для мобильного фронта и преобразовать его в обобщенный запрос.Но это приводит к повторному коду.Я немного запутался между одним слоем и двумя слоями.

Я знаю, это большой вопрос для чтения.Но спасибо за ваше время и ответы заранее.

Ответы [ 2 ]

1 голос
/ 09 декабря 2011

  1. Если существуют действия / условия, которые похожи по назначению или по тому, на что они действуют, их можно объединить в классы, имеющие несколько методов-обработчиков. Например, все сервлеты, которые действуют на пользователей, могут быть объединены в один класс. Имеет ли это смысл, зависит от информации, которой у нас нет.

  2. Сколько слоев должно у вас есть? Не знаю В общем, есть как минимум один уровень обслуживания. Сервисы объединяют функциональность DAO в транзакционные единицы. Обработчики условий управляют интерфейсом между веб-и бизнес-уровнями.

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

Если вы стремитесь к офигительной простоте, то что-то вроде Фронтмен медведя - это тонкий, симпатичный слой, который избавляет от множества сложностей и шума. Что-то вроде Guice Servlets позволяет вводить зависимости без полноценного Spring / etc. стек.

Классы, которые обрабатывают определенный URL (или «команду» - см. Любую комбинацию команд документацию), не обязательно должны быть фактическими сервлетами; они могут быть общими классами.

Они могут быть сервлетами - но чем слабее связь с вашей спецификацией сервлета, тем проще будет тестировать и расширять.

Получить URL-адрес для «команды» можно так же просто, как поиск команды на карте, создание экземпляра соответствующего класса, передача различных артефактов (например, параметров запроса и сеанса) и вызов метода в реализации. , В некотором смысле, каждая структура в конечном итоге работает так на некотором уровне.

0 голосов
/ 09 декабря 2011

Это просто мнение, но:

  1. Я бы назначил каждый сервлет ответственным за один ресурс.Так что разные сервлеты для пользователей, групп, бронирования, мест, но один и тот же сервлет для списка пользователей и формы редактирования пользователя.
  2. Обычно вам нужен один слой («сервис»), чтобы сделать ваш «DAO» DAO.Сервисный уровень отвечает за вашу бизнес-логику, DAO только вставляют / обновляют / извлекают записи из БД, а контроллеры подготавливают данные для просмотра ИЛИ обрабатывают сервисным уровнем.Ваши сервлеты отвечают за обработку данных, отправляемых на сервер.Необработанные данные не покидают слой сервлета.
  3. Миграция в какую-то инфраструктуру MVC (Spring?).Это сделает вашу жизнь намного проще.
...