Поиск шаблонов проектирования для изоляции слоев каркаса друг от друга

Question

Мне интересно, есть ли у кого-нибудь опыт "изоляции" объектов инфраструктуры друг от друга (Spring, Hibernate, Struts). Я начинаю видеть «проблемы» дизайна, когда объект из одного фреймворка используется в другом объекте из другого фреймворка. Я боюсь, что мы создаем тесно связанные объекты.

Например, у меня есть приложение, в котором у нас есть DynaActionForm с несколькими атрибутами ... одним из которых является POJO, сгенерированный инструментами Hibernate. Этот POJO используется повсеместно ... JSP заполняет его данными, действие Struts отправляет его на уровень обслуживания, DAO сохраняет его ... ack!

Теперь представьте, что кто-то решает провести небольшой рефакторинг этого POJO ... так что это означает, что все JSP, Action, Service, DAO должны быть обновлены ... что довольно болезненно ... быть лучше?!

Есть книга под названием «Основные шаблоны J2EE: лучшие практики и стратегии проектирования» (2-е издание) ... стоит ли на это смотреть? Я не верю, что это затрагивает какие-то конкретные фреймворки, но похоже, что это может дать некоторое представление о том, как правильно наложить слой на приложение ...

Спасибо!

Answer 1

Например, у меня есть приложение, в котором у нас есть DynaActionForm с несколькими атрибутами ... одним из которых является POJO, сгенерированный инструментами Hibernate. Этот POJO используется повсеместно ... JSP заполняет его данными, действие Struts отправляет его на уровень обслуживания, DAO сохраняет его ... ack!

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

Теперь представьте, что кто-то решает провести небольшой рефакторинг этого POJO ... так что это означает, что все JSP, Action, Service, DAO должны быть обновлены ... что довольно болезненно ... быть лучше?!

Конечно, вы могли бы прочитать «Бины» из базы данных на уровне слоя DAO, отобразить их в «Объекты домена» на уровне обслуживания и отобразить Объекты домена в «Объекты значения» для уровня представления, и у вас будет очень низкая связь. Но тогда вы поймете, что:

1. Добавление столбца в базу данных обычно означает добавление некоторой информации в представление и наоборот.
2. Дублирование объектов и отображений чрезвычайно болезненно делать и поддерживать.

И вы забудете эту идею.

Есть книга под названием «Основные шаблоны J2EE: лучшие практики и стратегии проектирования» (2-е издание) ... стоит ли на это смотреть? Я не верю, что это затрагивает какие-то конкретные фреймворки, но похоже, что это может дать некоторое представление о том, как правильно наложить слой на приложение ...

Эта книга была «демонстрацией» того, как реализовать (сверхинженерные) приложения, использующие весь стек J2EE (с EJB 2.x), и почему-то всегда считалась слишком сложной (слишком много шаблонов). Кроме того, сегодня он явно устарел. Так что это интересно, но его нужно принимать с гигантским зерном соли.

Другими словами, я бы не рекомендовал эту книгу (по крайней мере, конечно, не так, как это было бы в современном состоянии) Вместо этого взгляните на шаблоны реального мира Java EE - переосмысление передового опыта (см. Главу 3 - Отображение базовых шаблонов J2EE в Java EE) и / или литературу Spring, если вы не используют Java EE.

Answer 2

Во-первых, избегайте Struts 1. Необходимость расширения класса фреймворка (например, DynaActionForm) является одной из причин, по которой этот фреймворк больше не является хорошим выбором.

Вы не используете весенние занятия в обычных сценариях. Spring неинвазивен - он просто соединяет ваши объекты. Вы зависите от этого, только если используете некоторые интерфейсы, такие как ApplicationContextAware, или если вы используете расширения hibernate или jdbc. Использование этих расширений вместе с hibernate / jdbc вполне нормально, и это не является нежелательной связью.

Обновление: если вы вынуждены работать со Struts 1 (честно, попробуйте договориться о Struts 2, Struts 1 устарел!), Обычным способом было создать копию класса Form, содержащую точно такие же поля, но не расширяют класс фреймворка. Был бы фабричный метод, который принимает класс формы и возвращает простой POJO. Это дублирование кода, но я видел это на практике и не так уж плохо (по сравнению с использованием Struts 1 :))

Answer 3

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

Искусство хорошего дизайна - это понимание хороших практик и шаблонов, знание того, когда и как их применять, а также знание того, когда уместно их нарушать или игнорировать.

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

Наконец, можно создать систему, которая будет обрабатывать все проблемы, которые вас беспокоят, но будьте прагматичны - каждая цель, которую вы пытаетесь достичь, стоит дополнительного кода и API, которые вы должны будете внедрить для ее достижения.

Answer 4

Я думаю, что ваша проблема не так велика, как кажется.

Давайте представим, что вы действительно можете изменить в своем POJO:

1) имя своего класса: любая IDE с поддержкой рефакторинга автоматически внесет все необходимые изменения

2) добавить поле / метод: это почти всегда означает добавление новых функций, что всегда следует делать вручную и осторожно. Обычно это приводит к некоторым изменениям на вашем уровне обслуживания, очень редко в DAO и, как правило, по вашему мнению (jsp).

3) реализация методов изменения: при хорошем дизайне это должно вызывать любые изменения в других классах.

Вот и все, имхо.

Примите решение о технологии реализации логики занятости (EJB или Spring) и используйте ее средства внедрения зависимостей. Использование DI позволит различным частям вашей программы взаимодействовать друг с другом через интерфейсы. Этого должно быть достаточно для достижения необходимого (достаточно малого) уровня сцепления.

Answer 5

Я бы сказал, что Базовые Шаблоны J2EE: Наилучшие практики и стратегии проектирования (2-е издание) решают проблемы EJB 2.0, некоторые из которых сегодня будут рассматриваться как анти-шаблоны. Знания никогда не пропадают впустую, но я бы не сделал это своим первым выбором.

Проблема в том, что невозможно разделить все слои. Рефакторинг POJO означает изменение проблемы, которую вы решаете, поэтому все слои ДОЛЖНЫ быть изменены. Обойти это невозможно.

Чистое разделение слоев, которые не знают друг друга, требует большого количества дублирования, перевода и отображения. Не поддавайтесь идее, что слабая связь означает, что эта работа исчезнет.

Одна вещь, которую вы можете сделать, - это иметь сервисный уровень, который выражается в виде XML-запросов и ответов. Он вынуждает вас отображать XML на объекты на стороне службы, но он отделяет пользовательский интерфейс от остальных.