Поделиться через

Физическая модель: архитектура приложения

  • Статья

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

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

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

  • Часто ли происходит изменение компонента, что затрудняет распространение обновлений?
  • Будет ли компонент использоваться другими приложениями, например общим компонентом проверки безопасности?
  • Выполняет ли компонент длительные вычисления или выполняет такие функции, как печать, которые можно выгрузить на сервер?
  • Можно ли повысить безопасность компонента, разместив его на сервере?

Правильное размещение компонентов приложения также может изолировать команду разработчиков от дорогостоящих переопределения, если система или расположение данных изменяется. Например, путем размещения правил доступа к данным на уровне данных, а не в хранимых процедурах, приложение более легко изолировано от зависимости от определенной СУБД. Это не только изменения, ограниченные и проверочные секции, но и источники данных могут быть изменены, и данные могут быть распределены без фундаментального изменения приложения.

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

Концептуальная модель: требования к приложениям

Логическая модель: определение приложения и планирование