Первые несколько предостережений:
- Это субъективно
- Я согласен с SidCool, что ответ заключается в том, чтобы взглянуть на некоторые существующие фреймворки веб-приложений.Во всяком случае, просто чтобы узнать, как они это делают.
- Я большой поклонник внедрения зависимостей
Чтобы ответить на ваши вопросы:
- Нелегко передавать данные в атрибутах запроса, потому что: это небезопасно;это немного невидимая сумка вещей - всегда лучше, если вы видите выходные объекты в сигнатуре типа;в какой-то момент вы захотите сохранить две вещи в атрибутах запроса под одним и тем же именем
- Внедрение зависимостей - это путь в будущее.Выполнение статического вызова плохо, потому что: теперь вы тесно связали два объекта, что затрудняет повторное использование, а также усложняет тестирование
- Я бы определенно взглянул на некоторые другие фреймворки здесь.Большинство из них, как правило, имеют один сервлет отправки, я думаю, вы в конечном итоге напишите много очень похожих на вид сервлетов.Многие фреймворки также будут использовать рефлексию, чтобы попытаться выполнить преобразование между запросом и POJO как можно раньше и как можно проще.
Другое:
- Все ваши действия не соответствуют параметрам, т. Е.? Method = [список, просмотр, удаление, редактирование].Часто предпочтительнее использовать маршруты (например, index.html обычно используется для «списка»).
Чтобы ответить на ваши отзывы / вопросы из комментариев:
Выполняетсяна более старой версии Java
Ничего себе, это отстой.Однако есть фреймворки, работающие на Java 1.4.Spring MVC будет моей рекомендацией, но здесь больше .Тем не менее, причина, по которой я предложил взглянуть на другие фреймворки, заключалась не просто в их использовании, а в большей степени вдохновляться ими.Написание собственной платформы веб-приложений - это практически обряд и может быть довольно весело.Написание этого в такой ограниченной среде только добавляет к проблеме.
Что я бы предложил:
- Попробуйте недавнюю среду Java или даже не Java (например, Ruby onRails), просто чтобы посмотреть, что возможно
- Когда вы пишете свой собственный единственный фреймворк, просто используйте 1 сервлет и отправьте его на различные «контроллеры».Причина этого в том, что сервлеты не очень хороши для того, чтобы позволить вам собрать все ваше приложение (то, что делает Spring MVC, загружает «приложение» с помощью ContextListener, а затем сервлеты и фильтры ищут «приложение» из ServletContext)
Плотная связь статического
Плотная связь - это когда два объекта нельзя использовать друг без друга, никогда.Вы спросите, почему это плохо?Потому что вы никогда не сможете повторно использовать код для чего-то другого (скажем, если вы решили загрузить некоторые данные из файла, ввели слой кэширования, использовали его в другом проекте и т. Д.).Самое главное, некоторые скажут, что это трудно проверить.Это потому, что вы не можете просто заменить объект, который вы вызываете статически, другим.Интерфейсы обычно используются для разъединения объектов, но на самом деле вы можете сделать это, просто установив объект посредством внедрения зависимостей (что является сложным способом сказать: поместите его в конструктор или как установщик).
OOи быть инженером-строителем
Все хорошо.Некоторые из лучших программистов, которых я знаю, начинали не так.Для меня использование шаблона внедрения зависимостей - отличный способ написать «хороший» код по умолчанию.Примечание: если вы посмотрите на Dependency Injection, вам не нужна инфраструктура для него.Вам просто нужно создать все ваши объекты в одном месте, и все ваши объекты должны получить все свои зависимости либо в конструкторе, либо в установщике.Допускаются не статические методы или синглтоны.
В чем разница
Альтернатива «в чем разница», которая лучше иллюстрирует то, что я имею в виду, будет выглядеть так:
// code in your application builder
// assuming an interface called UserDAO
UserDAO userDAO = new STKUserDAO();
CommitmentItemForm form = new CommitmentItemForm(userDao);
public class CommitmentItemForm {
private final UserDAO userDao;
public CommitmentItemForm(UserDAO userDao) { this.userDao = userDao; }
public Object edit(HttpServletRequest request) {
...
deptSupervisorList = userDao.getList(authenticatedUser.getDepartment());
...
}
}
против
public class CommitmentItemForm {
public CommitmentItemForm()
public Object edit(HttpServletRequest request) {
...
deptSupervisorList = STKUserDAO.getList(authenticatedUser.getDepartment());
...
}
}
Статический метод определенно выглядит так, как будто он меньше работает, так почему же он так плох? По сути, это потому, что в статической версии вы никогда не можете искать deptSupervisorList из чего-либо, кроме STKUserDAO. В нестатической версии вы можете предоставить любую реализацию интерфейса UserDAO. Это означает, что вы можете использовать один и тот же код CommitmentItemForm независимо от того:
- Вы делали это в тесте и создавали пробную версию UserDAO, которая каждый раз возвращала исключение, чтобы вы могли проверить это
- Вы обнаружили, что вам нужно получить список своих отделов из веб-службы JSON HTTP REST или из файла
Из подписи CommitmentItemForm также сразу видно, что для функционирования ему нужен UserDAO (потому что это требуется в конструкторе).
Это одна из тех маленьких вещей, которые, если вы сделаете это со всем своим кодом, вы обнаружите, что ваш код не только более гибкий, он более тестируемый, более многократно используемый, и части, которые вы внезапно обнаружите, должны изменить в будущем лучше изолированы.