Стандартные практики Java / J2EE и выбор дизайна

Question

У меня есть пара вопросов по дизайну / архитектуре, которые всегда возникают в нашем магазине. Я сказал «наш», а не «я» лично. Некоторые решения были приняты и приняты, когда J2EE был впервые представлен, поэтому есть некоторые неудачные варианты дизайна и некоторые хорошие.

1. В веб-среде, как вы работаете с фильтрами. Когда следует использовать фильтры J2EE, а когда нет? Можно ли иметь много фильтров, особенно если в них слишком много логики. Например, в нашем процессе аутентификации много логики. Если вы являетесь этим пользователем, перейдите на этот сайт, а если нет - на другой. Трудно отладить, потому что один URL-путь может привести к отображению разных целевых страниц.

2. Файлы комплектов ресурсов ресурса для значений замещения в файлах JSP. Похоже, что в сообществе Java единодушным является использование файлов комплектов, содержащих метки и заголовки, для анализа jsp. Я вижу выгоду, если вы занимаетесь разработкой на многих языках и переключаете значения меток в зависимости от локали. Но что, если вы не работаете с несколькими языками? Если каждый фрагмент статического текста в файле JSP или другом файле шаблона действительно должен быть помещен в файл свойств. Еще раз, мы сталкиваемся с проблемами отладки, когда текст может не отображаться из-за неправильного написания ключей значения свойства или поврежденных файлов свойств. Также у нас есть процесс, когда графические дизайнеры отправляют нам html-шаблоны, а затем мы конвертируем их в jsp. Кажется более сложным удалить статический текст, добавить ключ, добавить ключ / значение в файл свойств и т. Д.

например. Файл tags.properties может содержать имя пользователя: метка. Это заменяется некоторым ключом и передается пользователю.

3. Модульное тестирование для всех разработок J2EE - мы не поощряем модульное тестирование. Некоторые люди делают, но я никогда не работал в магазине, который использует обширное модульное тестирование. Как только место заняло, а затем, когда наступило время хруста, мы прекратили модульное тестирование, а затем через некоторое время юнит-тесты были бесполезны и никогда не скомпилировались. Большая часть разработок, которые я сделал, была связана с серверами, разработкой веб-приложений, подключением к базам данных. Я вижу, где юнит-тестирование может быть громоздким, потому что вам нужна среда для юнит-тестирования. Я думаю, что манифесты модульного тестирования поощряют разработчиков не подключаться к внешним источникам. Но похоже, что основная часть тестирования должна быть подключена к базе данных и запускать весь код, а не только конкретный модуль. Так что это мой вопрос: должны ли мы писать модульные тесты во всех случаях для всех типов разработки (как вы видите в разработке J2EE, ориентированной на CRUD)? И если мы не будем писать модульные тесты, какие другие механизмы тестирования для разработчиков мы могли бы использовать?

Отредактировано: Вот несколько хороших ресурсов по некоторым из этих тем.

http://www.ibm.com/developerworks/java/library/j-diag1105.html

Answer 1

1. Перенаправление - это более простой способ обработки разных страниц в зависимости от роли.Фильтр может использоваться просто для аутентификации, чтобы получить объект User и любые связанные роли в сеансе.

   Как сказал Джеймс Блэк, если бы у вас был центральный контроллер, вы могли бы избавиться от необходимости помещать эту логику в фильтры.Для этого вы должны сопоставить центральный контроллер со всеми URL-адресами (или со всеми нестатическими URL-адресами).Затем фильтр передает пользователя и роли на центральный контроллер, который решает, куда отправить пользователя.Если пользователь пытается получить доступ к URL-адресу, для которого у него нет разрешения, этот контроллер может решить, что с этим делать.

   Большинство основных веб-сред MVC следуют этому шаблону, поэтому просто ознакомьтесь с ними для лучшего понимания.об этом.

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

3. Тестирование - это большая ошибка.По моему опыту, очень дисциплинированный подход, основанный на тестировании, может устранить 90% стресса при разработке этих приложений.Но юнит-тестов недостаточно.

   Я использую три вида тестов, как указано сообществом Agile:

   • приемочные / функциональные тесты - заказчик определяет их с каждым требованием, и мыне отправляйте, пока они не пройдут все (смотрите FitNesse, Selenium, Mercury)
   • интеграционные тесты - убедитесь, что логика верна и что проблемы не сталкиваются между уровнями или с реалистичными данными (посмотрите на Cactus, DBUnit, Canoo WebTest)
   • модульные тесты - как определяет использование и ожидания класса, так и обеспечивает уверенность в том, что критические изменения будут быстро обнаружены (см. JUnit, TestNG)

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

• взрыв необходимых коммуникаций, поскольку разработчики пытаются выяснить, как использовать (или как кто-то нарушил) классы друг друга
• нет связии повышенный риск из-за «бункеров» - областей, где только один разработчик касается кода и в котором компания полностью зависит от этого разработчика

Даже если это только я, слишком легко забыть почемуЯ поместил этот маленький кусочек особой логики в класс шесть месяцев назад.Затем я нарушаю свой собственный код и должен выяснить, как ... это большая трата времени и ничего не делает для снижения уровня стресса!Кроме того, если вы заставите себя продумать (и напечатать) тест для каждой важной функции в своем классе и выяснить, как изолировать любые внешние ресурсы, чтобы вы могли передать имитирующую версию, ваш дизайн неизмеримо улучшится.Поэтому я склонен работать в первую очередь на тестировании.

Пожалуй, наиболее полезным, но менее часто выполняемым, является автоматическое приемочное тестирование.Это то, что гарантирует, что разработчики поняли, о чем просил клиент.Иногда это остается за QA, и я думаю, что это нормально, но идеальная ситуация - та, в которой они являются неотъемлемой частью процесса разработки.

Это работает так: для каждого требования план тестирования превращается в сценарий, который добавляется в набор тестов.Тогда вы смотрите, как это не удается.Затем вы пишете код, чтобы он прошел.Таким образом, если кодировщик работает над изменениями и готов к регистрации, он должен выполнить чистую сборку и выполнить все приемочные тесты.Если что-то не получилось, исправьте, прежде чем вы сможете зарегистрироваться.

«Непрерывная интеграция» - это просто процесс автоматизации этого шага - когда кто-нибудь регистрирует код, отдельный сервер проверяет код и запускает все тесты. Если какие-либо из них были повреждены, он спамит последним застройщиком, пока они не будут исправлены.

Однажды я консультировался с командой, у которой был один тестер. Этот парень работал над планами испытаний вручную, целый день. Когда произошли изменения, какими бы незначительными они ни были, ему придется начинать все сначала. Я построил для них электронную таблицу, в которой указывалось, что на одном экране было более 16 миллионов возможных путей, и они потратили 10 тысяч долларов на Mercury Test Director в спешке! Теперь он составляет электронные таблицы и автоматизирует планы тестирования, в которых они используются, поэтому они проводят довольно тщательное регрессионное тестирование без постоянно растущих временных требований.

Как только вы начали автоматизировать тесты на каждом уровне вашего приложения (особенно если вы работаете в тестовом режиме), происходит удивительная вещь. Беспокойство исчезает!

Так что нет, это не обязательно. Но если вы беспокоитесь о техническом долге, о большом развертывании в эти выходные или о том, собираетесь ли вы что-то сломать, пытаясь быстро измениться, чтобы удовлетворить внезапно возникающие потребности клиентов, вы можете более тщательно исследовать Первая разработка.

Answer 2

1. Ожидается, что фильтры в целом будут выполнять меньшие функциональные единицы, и цепочка фильтров будет использоваться для применения фильтров по мере необходимости. В вашем случае, возможно, рефакторинг может помочь перенести некоторую логику в дополнительные фильтры, а логику перенаправления можно несколько централизовать через контроллер, чтобы было легче отлаживать и понимать.
2. Пакеты ресурсов необходимы для обеспечения гибкости, но если вы абсолютно уверены, что сайт будет использоваться в одной локали, вы можете пропустить его. Возможно, вы можете перенести часть работы по сопровождению комплектов на дизайнеров, то есть предоставить им доступ к комплектам ресурсов, чтобы получить HTML-код с установленными ключами.
3. Модульное тестирование гораздо проще реализовать в начале проекта, чем встраивать его в существующий продукт. Для существующего программного обеспечения вы все еще можете реализовать модульные тесты для новых функций. Тем не менее, это требует определенной настойчивости со стороны руководителей команд, и команда должна согласиться с необходимостью проведения юнит-тестов. Анализ кода для модульных тестов помогает, и решение о том, какие части кода должны быть полностью охвачены, может помочь разработчикам. Инструменты / плагины, такие как Coverlipse, могут указывать охват модульного тестирования, но они имеют тенденцию рассматривать каждый возможный путь кода, некоторые из которых могут быть тривиальными.
   В одном из моих предыдущих проектов юнит-тесты были просто обязательными, и юнит-тесты запускались автоматически после каждой регистрации. Однако это не было разработкой, управляемой тестами, поскольку тесты в основном были написаны после того, как были написаны небольшие куски кода. TDD может привести к тому, что разработчики будут писать код для работы только с модульными тестами, и в результате разработчики могут потерять общую картину разрабатываемого ими компонента.

Answer 3

В веб-среде, как вы работаете с фильтрами. Когда следует использовать фильтры J2EE, а когда нет?

Фильтры предназначены для управления / изменения / перехвата фактических запросов / ответов / сеансов. Например: настройка кодировки запроса, определение вошедшего в систему пользователя, перенос / замена запроса или ответа, определение сервлета, которому он должен переслать запрос, и т. Д.

Для управления фактическим пользовательским вводом (параметрами) и выводом (результатами и местом назначения) и для выполнения реальной бизнес-логики вы должны использовать сервлет.

Файлы комплектов ресурса свойств для значений замены в файлах JSP.

Если вы не делаете i18n, просто не используйте их. Но если вы когда-нибудь вырастете и клиент / пользователи захотят i18n, то вы будете рады, что вы уже готовы. И не только это, но и упрощает использование CMS для редактирования контента, просто используя java.util.Properties API.

Модульное тестирование для всех разработок J2EE

JUnit может позаботиться об этом. Вы также можете рассмотреть возможность «официально» проводить только пользовательские тесты. Создайте несколько вариантов использования и протестируйте его.

Answer 4

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

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

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

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

Это гарантирует, что эта ошибка не вернется, что вы исправили ее и обновили модульный тест.

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