Ищете шаблоны проектирования, чтобы изолировать рамки друг от друга

Question

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

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

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

Есть книга под названием Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition) ... это стоит посмотреть? Я не верю, что это касается каких-либо конкретных фреймворков, но похоже, что это может дать некоторое представление о том, как правильно сложить приложение ...

Спасибо!

Answer 1

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

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

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

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

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

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

Есть книга под названием Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition) ... это стоит посмотреть? Я не верю, что это касается каких-либо конкретных фреймворков, но похоже, что это может дать некоторое представление о том, как правильно сложить приложение ...

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

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

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

Answer 5

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

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

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

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