Понимать архитектуру приложения - PullRequest
2 голосов
/ 02 июля 2011

Я - программный разработчик, работающий над веб-приложением на Java.

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

Может кто-нибудь помочь мне понять это?

Below is the arch image

Ответы [ 3 ]

2 голосов
/ 02 июля 2011

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

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

Под бизнес-логикой я подразумеваю код Java (или другого языка), который выражаетреалии бизнеса клиента.Например, в приложении для розничной торговли нам может потребоваться определить скидки для определенных объемов заказов.Таким образом, слой пользовательского интерфейса хочет отобразить цену для заказа клиента.Он сам не имеет никакой логики дисконтирования, вместо этого он говорит слою бизнес-логики: «Клиент X - это виджеты N и M zettuls, когда мы можем поставить и сколько мы будем взимать», и бизнес-логика определяет цену для этогоклиент, который может зависеть от всех видов вещей, таких как статус клиента, количество вещей, которые у нас есть в наличии, размер заказа и так далее.Пользовательский интерфейс просто получает ответ £ 450, который будет доставлен 16 сентября , и отображает его.

Это приводит к таким вопросам, как "почему отделить бизнес-логику от ее собственного уровня?"Есть несколько возможных причин:

  • Бизнес-логика может использоваться и совершенно другим пользовательским интерфейсом
  • Она уже существует из какой-то более старой системы
  • Нашамозги слишком малы, чтобы думать о UI и Business Logic одновременно
  • У нас разные команды, работающие над UI и BL - необходимы разные навыки

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

В каждом слое много материала.Предлагаем начать с чтения одного из них и задать конкретные вопросы, если вы застряли.

0 голосов
/ 02 июля 2011

Уровень приложения - где находится базовая логика приложения (представьте себе базовую консольную программу).

  • База данных - MySQL, Oracle ... сервер
  • DOs - Сокращение от доменных объектов. Если анемия обычно ограничивается геттерами / сеттерами и может быть синонимом сущностей (@Entity).
  • Объекты доступа к данным - Объекты, использующие шаблон DAO для извлечения объектов домена из базы данных. Может считаться эквивалентным как DAL (Уровень доступа к данным), хотя это может не подходить здесь. Обычно используется структура сохранения / отображения, такая как Hibernate или iBatis.
  • Модель предметной области - Где домен (домен, являющийся предметом изучения / анализа требований). Классы упаковываются и связываются (один-к-одному, многие-к-одному, ...). Иногда есть даже составные в других классах контейнера.
  • Базовые службы приложений - Классы групповых услуг, которые можно приравнять к уровню бизнес-логики (BLL). Службы Biz обрабатывают модель домена, службы приложений относятся к приложению (методы не управляют доменом) и не уверены, что должны делать системные службы. Я также не уверен, в чем различие между ядром и блоком службы приложений.
  • Фасад / Интерфейс - Здесь все коммуникации осуществляются с другими уровнями. Это помогает полностью понять интерфейсы и шаблон фасада.
  • TO : перенос объектов. Относится к объектам домена и используется для передачи, как следует из названия.

Веб-уровень - добавлена ​​вся логика, позволяющая сделать приложение доступным из Интернета.

  • Business Delegate : заблокировать с использованием шаблона делегирования? Здесь он, по-видимому, играет промежуточного звена между фасадом приложения и уровнем представления данных, используя TO.
  • Модель : Понятие относительно шаблона и вариантов MVC. С JSF я знаю, что бины обычно связаны с JSP. Эту модель следует отличать от модели предметной области. Он создан для целей представления и может содержать информацию, которая не имеет ничего общего с данными, которыми манипулируют на уровне приложения, и относится к веб-уровню.
  • Просмотр : Понятие относительно шаблона и вариантов MVC. JSP представляют отдельные страницы и используют собственную разметку.
  • Сессия : поиск теории сессий (необходимо, поскольку HTTP не имеет состояния).
  • ApplicationContext : Группирует экземпляры / настройки, которые могут быть извлечены из любого места. Часто ассоциируется в мире Java со средой Spring. Не путать с UglyGlobalVar / singletons.
  • Фронт-контроллер : Можно рассматривать как эквивалент контроллера из MVC, хотя шаблон фронт-контроллера выглядит более конкретным. Сервлеты рассматриваются как контроллеры, так как они управляют связью (GET, POST ...) и координируют модель / представление. Не знаком со Struts, но представьте, что платформа реализует классы для представления действий пользователя.
  • Уровень представления : просто вся логика, используемая для внешнего представления.
  • Фильтры : Может использоваться для фильтрации запросов, например, для перенаправления запроса на страницу входа.

Не стесняйтесь добавлять / исправлять это описание.

0 голосов
/ 02 июля 2011

Похоже, стандартное "предприимчивое" приложение для меня.

Интерфейс

Это приложение.в первую очередь предназначен для использования через веб-браузеры людьми.Этот интерфейс или уровень пользовательского интерфейса (в широком смысле) строится с использованием инфраструктуры MVC Struts.Если вы не знаете MVC, то стоит прочитать этот термин.

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

Итак, предоставляется 2 вида интерфейса.

Бизнес-логика

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

Причина, по которой они разделили систему, может варьироваться.Если это очень простое, маленькое приложение.тогда эти абстракции не окупятся, так что, вероятно, это довольно сложная система.Возможно приложение.Уровень - это какое-то устаревшее приложение.и они хотели поставить лучший интерфейс поверх него.Возможно приложение.Уровень и веб-уровень оказались использовать разные технологии стека.Или, возможно, приложение.Уровень используется многими другими внешними системами.Это также упрощает обновление каждой услуги / замену каждой услуги и т. Д., Поэтому, возможно, они ожидают этого.В любом случае, это похоже на очень распространенный тип SOA-дизайна.

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

...