Это определение архитектуры в порядке?Многоуровневый (Spring / Multi DB) - PullRequest
Новая
       29

Это определение архитектуры в порядке?Многоуровневый (Spring / Multi DB)

1 голос
/ 12 января 2011

Вот фон, возможно, некоторые термины неверны, так как я не эксперт в этой области:

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

  • Уровень представления : использование ASP.NET с C #.Здесь запрограммирована логика веб-страницы, но бизнес-логика определяется на отдельном слое
  • Уровень определения модели : группирует все бизнес-объекты системы (т. Е. Документ, Пользователь, Папка).На объекте не определены действия (методы, кроме методов получения и установки).Он просто представляет запись из таблицы (или объединения таблиц) в базе данных
  • Уровень бизнес-логики : предложения здесь называются "Двигатели" ,и у них есть все взаимодействия бизнес-правил для каждого бизнес-объекта (т. е. DocumentEngine имеет все методы, которые представляют бизнес-правила для обработки документов в системе, такие как добавление, удаление, обновление и т. д.).Эти методы используют (в качестве параметров) и возвращают бизнес-объекты (определенные в определении модели) во многих случаях, в других просто используют / возвращают примитивы.
  • Уровень доступа к данным : этот уровень извлекает данные(с использованием службы доступа к данным) из базы данных и преобразует в бизнес-объекты (создание экземпляра объекта, определенного в MDL, и установка значений его свойств с соответствующими значениями полей, извлеченными из БД).Как и уровень бизнес-логики, он использует и возвращает бизнес-сущности или примитивы, ранее упомянутые как отдельный объект или набор объектов (с использованием обобщений)
  • Служба доступа к данным : Использование Simple FactoryШаблон, создает соединение с базой данных в соответствии с указанными параметрами, поэтому он может извлекать информацию из нескольких механизмов БД.

Хорошо, тогда, когда мне нужно, например, список документов, я открываю веб-страницу, вызывается бизнес-правило с правильными параметрами (т. Е. Идентификатор папки для этого случая).Затем уровень доступа к данным использует DAS для запроса к базе данных и преобразует извлеченные записи в бизнес-объекты (определенные в MDL).Эта бизнес-сущность (или совокупность сущностей) возвращается через слои на уровень представления.

Теперь, возможно, это не лучшая архитектура, но она мне очень понравилась, так что теперь яЯ пытаюсь использовать тот же подход, но использую Java с Spring MVC в качестве уровня представления, поэтому у меня будет

  • Presentation (Spring MVC)
  • Уровень определения модели
  • Уровень бизнес-логики
  • Уровень доступа к данным
  • Служба доступа к данным (фабрика баз данных с использованием JDBC)

Бизнес-требования: «создать легковесное корпоративное веб-приложение,его можно легко расширить, подключить к нескольким БД (Oracle, SQL Server, mySQL) с минимальными изменениями кода, поддержкой I18N, возможностью регистрации действий пользователей, несколькими режимами представления (Web, Mobile) и очень хорошо смотрится как приложения Web2.0XD "

Что ты думаешь?Это хорошее определение архитектуры?Должен ли я что-то изменить, чтобы соответствовать требованиям бизнеса?

Заранее благодарим за сотрудничество

1 Ответ

0 голосов
/ 14 января 2011

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

В начале восьмидесятых годов введение ориентации объекта показало, что разделение данных и поведения приводит к большей взаимосвязанности и меньшей сплоченности.Разделение определения модели и бизнес-логики - плохая идея.Он имеет тенденцию возникать из-за архитектур на основе реляционных баз данных, в которых, как правило, нет места для управления поведением.

Из-за доминирования СУРБД эти архитектуры возникают очень часто.Это не делает их хорошими.Основные возникающие проблемы:

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

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

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

...