Дизайнерските модели правят по-добри приложения за J2EE

От самото си създаване J2EE (Java 2 Platform, Enterprise Edition) опрости изграждането на корпоративно приложение в Java. Тъй като J2EE става все по-широко възприет, разработчиците осъзнават необходимостта от дефинирани подходи, които едновременно опростяват и стандартизират изграждането на приложения. Можете да започнете да постигате тази цел, като стандартизирате архитектурния слой на приложението си .

Архитектурният слой обикновено капсулира техническата сложност на приложението, независимо от бизнес логиката, като по този начин осигурява свободно свързване между бизнес функционалността и основната техническа инфраструктура. В тази статия обяснявам един нововъзникващ метод за изграждане на архитектурата на приложенията за проекти J2EE - такъв, който използва модели на проектиране, за да осигури стандартизацията и простотата, които изисква добрата архитектура.

Архитектура на приложенията и J2EE

J2EE е страхотна инфраструктурна технология. Той осигурява единен стандарт за задачите от по-ниско ниво на технологичния стек, като комуникация с база данни или разпространение на приложения. J2EE обаче не води разработчици да изграждат успешни приложения. Създателите на J2EE, поглеждайки надолу към технологичния стек, се чудеха: „Как можем да стандартизираме тези API?“ Те трябваше да погледнат разработчиците на приложения и да попитат: „Как мога да дам на разработчиците градивните елементи, които са им необходими, за да се съсредоточат върху тяхното бизнес приложение?“

Когато започват нов проект за J2EE, някои членове на екипа често питат: „Ако J2EE сам по себе си е архитектура, защо се нуждаем от повече?“ Много разработчици поддържаха това погрешно схващане в ранните дни на J2EE, но опитни разработчици на J2EE разбират, че J2EE не успява да предостави архитектурата на приложенията, необходима за последователно доставяне на висококачествени приложения. Тези разработчици често използват дизайнерски модели, за да запълнят тази празнина.

Дизайнерски модели

При програмирането дизайнерските модели ви позволяват да използвате колективния опит на общността на разработчиците, като споделяте проблеми и решения, които са от полза за всички. Моделът на дизайна трябва да улови дефиницията и контекста на проблема, възможно решение и последствията от решението.

За целите на архитектурата на приложенията на J2EE моделите на проектиране се разделят на две категории: общи модели за разработка на софтуер и модели, които идентифицират специфични предизвикателства на J2EE. J2EE-специфичните дизайнерски модели идентифицират минималния набор от известни проблеми, които солидната архитектура на приложението трябва да реши. Първата група, тази на моделите за разработване на софтуер, които не са специфични за J2EE, се оказва еднакво мощна - не за идентифициране на проблеми, а за насочване на архитектурното изграждане.

Нека разгледаме всяка област по-подробно.

J2EE дизайнерски модели

J2EE дизайнерските модели се развиват през последните няколко години, тъй като общността на Java е натрупала опит в J2EE. Тези модели на проектиране идентифицират потенциални проблеми, възникнали при използването на различните J2EE-определени технологии и помагат на разработчиците да конструират изискванията на архитектурата на приложението. Популярният модел за дизайн на Front Controller, например, трансформира неструктуриран код на сървлета в контролер, напомнящ на усъвършенстваната разработка на GUI (графичен потребителски интерфейс).

Схемите за проектиране на J2EE идентифицират онези проблеми в домейна, които най-вероятно ще се появят във вашите J2EE проекти. Всъщност, ако проблемите бяха редки, дизайнерските модели нямаше да се развият, за да ги посрещнат. Имайки това предвид, ще се възползвате от решаването на всеки проблем с домейн във вашата архитектура. За да ги разрешите всички, създайте контролен списък, за да проверите вашата архитектура за пълнота. Този процес е в контраст с процеса за модели на проектиране на софтуерни разработки, които ще обсъдя по-нататък, тъй като трябва да ги прилагате само когато и ако е подходящо.

И така, къде намирате дизайнерските модели на J2EE? Sun Microsystems предлага две книги, които съдържат много модели на J2EE:

  • Проектирането на корпоративни приложения на J2EE BluePrint Group с платформата Java 2 (Enterprise Edition), Никола Касем и др. (Addison-Wesley, 2000; ISBN: 0201702770)
  • Основните модели на J2EE на групата Sun Professional Services : Най-добри практики и стратегии за дизайн, Deepak Alur, John Crupi и Dan Malks (Prentice Hall, 2001; ISBN: 0130648841)

(Вижте Ресурси за връзки към двете книги.)

Освен ресурсите на Sun, други публикации предлагат информация за модела на дизайна на J2EE, включително различни списания или уебсайтове на Java индустрията (като JavaWorld ), както и множество книги. (Виж ресурси за връзки с някои от тези сайтове, в това число JavaWorld " и Design Patterns страница Актуално Index).

Модели на проектиране на софтуерни разработки

Също така трябва да сте наясно с моделите за проектиране на софтуерни разработки, разделени на общи обектно-ориентирани (OO) дизайнерски модели и специфични за Java дизайнерски модели. Моделът Factory, например, представлява мощен модел на OO дизайн за капсулиране на създаването на обект, за да се даде възможност за повторно използване и да отговори на променящите се изисквания на системата. От своя страна, моделите за проектиране на езика Java отчитат спецификите на езика Java. Някои са уникални за Java и обикновено са неформални (например изключения и примитиви), докато други са OO модели, прецизирани, за да се прилагат за Java. Известната книга „Gang of Four“, „ Design Patterns“ от Ерик Гама и др., Разказва многобройни общи модели за разработка на софтуер, полезни за всички програмисти.

Не отхвърляйте тези модели просто защото те не са специфични за J2EE. Напротив, такива модели могат да се окажат също толкова мощни, ако не и повече, отколкото дизайнерските модели на J2EE, защото:

  • Докато моделите на проектиране на J2EE са нови и се развиват (защото J2EE е нов и се развива), другите модели се възползват от възрастта, тъй като индустрията има повече време да ги прегледа и усъвършенства.
  • Те често служат като основа, от която произтичат дизайнерските модели на J2EE.
  • Те изграждат основата, върху която се прилагат специфичните за J2EE решения. Правилното изграждане на тази основа повлиява широко здравината и разтегливостта на цялата архитектура. Ако не е конструиран правилно, фундаментът ще сведе до минимум полезността на архитектурата, независимо от това колко J2EE проблеми решава.

Не правете контролен списък, обхващащ моделите за разработка на софтуер, които вашата архитектура изисква, както бихте направили с моделите J2EE. Вместо това използвайте такива модели, където е подходящо, въз основа на специфичните предизвикателства на вашия проект. Много разработчици погрешно вярват, че техните продукти ще се подобрят, ако използват повече модели - или ако използват всички тях! Това обаче не е така. Използвайте дискретност и финес, когато решавате кои модели да използвате и как да ги използвате заедно.

Модели на проектиране: Къде е кодът?

Имайте предвид, че моделите на проектиране не се предлагат с точното изпълнение или изходния код, който ще използвате. Предложенията за дизайнерски шарки варират от оскъдни текстови описания до богата документация до евентуален примерен код. Предизвикателството идва в прилагането на мощните идеи на моделите. Тези идеи трябва да бъдат приложени към средата, в която ще бъдат използвани; средата определя правилното изпълнение.

Като аналогия, помислете за дизайнерски модел за изграждане на основата на къща. Моделът на проектиране идентифицира проблема, контекста и възможното решение за изграждане на основата - информация, изключително ценна за строителния работник в полето. Работникът обаче все още трябва да изгради основата. Няма ли този строителен работник да се възползва повече, ако му бъде дадена основа (подобно на разработчика на софтуер, на когото е дадено изпълнение)? Може би тази основа би била просто плоча от бетон, върху която къщата може да бъде построена. Проблемът: Фондацията трябва да се интегрира със самата къща и земята, където ще живее къщата. Как може такава предварително изградена основа да побере всички възможни етажни планове на къщата (правоъгълник, квадрат и други странни форми) и всички възможни пейзажи (на върха на хълм,насред гора и т.н.)?

Обратно в света на софтуера, възможността за използване на предварително изградени дизайнерски модели зависи от два фактора:

  • Изпълнението, а не индивидуалните дизайнерски модели, представлява решение. Решението може да включва множество дизайнерски модели и по този начин ще знае как играят отделните дизайнерски модели.
  • Решението трябва да бъде адаптивно, което отговаря на последния въпрос от аналогията на предварително изградената основа: основата трябва да може да се адаптира към терена и етажните планове. Както можете да си представите, ще е необходим изключително квалифициран майстор, за да изгради адаптивната основа, за разлика от стандартната основа.

Често срещани дизайнерски модели

Таблицата по-долу изброява някои често срещани дизайнерски модели както от J2EE източници, така и от по-широки OO модели.

Често срещани дизайнерски модели
J2EE дизайнерски модели Модели за разработване на софтуер
Фасада на сесията Сингълтън
Асемблер на обект на стойност Мост
Модел на локатор на услуги Прототип
Бизнес делегат Абстрактна фабрика
Композитен обект Муха
Манипулатор на списък със стойности Посредник
Локатор на услуги Стратегия
Композитен обект Декоратор
Обект на стойност Щат
Обслужване на работник Итератор
Обект за достъп до данни Верига от отговорност
Прихващащ филтър Контролер на изглед на модел II
Преглед на помощник Спомен
Композитен изглед Строител
Изглед на диспечера Фабричен метод

Нека да разгледаме два примера за шаблони за дизайн на J2EE: моделите Session Facade и Value Object И двамата демонстрират как моделите за проектиране на J2EE се фокусират върху проблеми, специфични за средата на J2EE, за разлика от моделите за проектиране на софтуер за разработване, които обикновено се прилагат за всяко усилие за разработване на приложения.

Пример: Шаблонът на сесийна фасада J2EE

Моделът на сесийна фасада е еволюирал от опит с Enterprise JavaBeans (EJB). Системите, изградени върху нововъведените обекти EJB (които комуникират с база данни) се забавят и обхождат. Тестването на производителността разкри проблеми, произтичащи от множество мрежови повиквания, направени при комуникация с EJB на обекта, което добави режийни разходи за установяване на мрежова връзка, сериализиране на данните както за изпращане, така и за получаване и други ефекти.

В отговор моделът на сесийна фасада подобри производителността, като централизира тези множество мрежови посещения в едно обаждане. Session Facade използва сесия EJB без състояние, за да посредничи между клиентското обаждане и необходимото EJB взаимодействие на обекта. Съществуват повече модели за подобряване на производителността на достъпа до база данни, включително Fast Lane Reader и шаблони за обект за достъп до данни.

Пример: Шаблонът Обект на стойност J2EE

Моделът Value Object J2EE също има за цел да подобри производителността на системи, които използват EJB през мрежата. Тези мрежови повиквания, индуциращи режийни от предишния пример, извличат отделни полета с данни. Например, може да имате Personлице с EJB методи като getFirstName(), getMiddleName()и getLastName(). С модела за дизайн на обект на стойност можете да намалите такива множество мрежови повиквания до едно повикване с метод на обекта EJB, като например getPersonValueObject(), който връща данните наведнъж. Този обект на стойност съдържа данните, които обектът EJB представлява и може да бъде достъпен при необходимост, без да се натоварват мрежовите разговори.

Пример: Flyweight OO модел

За пример на широко приложим модел за проектиране на ОО, помислете за модела Flyweight, който подобрява производителността на приложението чрез повторно използване на обекта. OO софтуерът произвежда режийни разходи - пропилени процесорни цикли, събиране на боклук и разпределение на паметта - когато създава и унищожава обект. Ако системата може да използва повторно тези обекти, можете да избегнете тези режийни разходи. Обектите обаче често не могат да се използват повторно, тъй като съдържат информация (наречена състояние ), специфична за текущия потребител на обекта. Моделът Flyweight осигурява подходи за преместване на това състояние на друго място, така че останалата част от обекта може да бъде използвана повторно.

Съберете ги всички заедно: Пример за постоянство

След като вече знаете основите, можете да започнете да прилагате дизайнерски модели в своите практики за разработка. Но как всъщност използвате шаблони? Започнете с идентифициране на домейн или технически проблем, изискващ решение. Постоянството - решаване на вековното несъответствие между обект и релационна база данни - представлява добър пример за повечето корпоративни приложения. Нека да видим стъпките, необходими за проектиране и изграждане на слой на устойчивост на архитектурата на приложението.

Следвайки традиционната OO архитектура и дизайн, създайте случаи на употреба, описващи вашите нужди за постоянство. Възможните случаи на употреба включват:

  1. Постоянството на обекта трябва да бъде прозрачно от гледна точка на разработчиците.
  2. Механизмите за устойчивост - EJB на обекти, обекти за достъп до данни и т.н. - трябва да се конфигурират на архитектурно ниво.
  3. Нашата архитектура трябва да използва J2EE технологии, но да капсулира зависимости J2EE. Би трябвало да можем да променим доставчиците на сървъри за приложения на J2EE, версиите на J2EE или да заменим напълно J2EE, без да се налага цялостен ремонт.
  4. Полученият слой на устойчивост трябва да бъде повторно използван за всички проекти. Това трябва да е част от нашата текуща архитектура на приложенията.

След като идентифицирате проблема, можете да решите кои модели да се прилагат. Не забравяйте, че за шаблоните J2EE трябва да определите кои модели се прилагат в проблемната област и да ги адресирате. За по-настойчивост са съответните модели за проектиране на J2EE (вижте книгите за модели на J2EE на Sun в ресурси):

  • Обект на стойност
  • Четец за бързо платно
  • Обект за достъп до данни
  • Фасада на сесията
  • Композитен обект
  • Манипулатор на списък със стойности

Тъй като ще използвате EJB, включете шаблоните Business Delegate и Service Locator, за да адресирате достъпа до EJB.

Освен това, решаването на втория и третия случай на употреба изисква традиционни модели за проектиране на софтуерно развитие. Как капсулирате зависимости и имате конфигурируеми механизми за постоянство? Някои приложими модели за разработване на софтуер включват:

  • Фабрика
  • Посредник
  • Стратегия