MVC Web-приложения vs. Web публикация БД

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

1) Получить запрос клиента на информацию
2) Составить запрос к БД
3) "Обернуть" ответ в HTML и послать клиенту.


Широко используется процедурный подход: пишутся функции под часто используемые
нужды и т.п.


Можно работать в ООП-стиле: разработать набор классов, отвечающих за
разнообразный функционал: анализатор запросов, генератор SQL-запросов,
обработчик шаблонов и т.п.

В определённый момент развития системы, встаёт вопрос не только разделения
логики от представления, но и применения более многоуровневой архитектуры.
Самая популярная и хорошо себя зарекомендававшая архитектура - это
Модель-Вид-Контроллер(Model-View-Controller) - MVC.
MVC подразумевает создание модели предметной области, т.е.
иерархии классов, соответсвующих реальным обьектам проблемной области.
Т.е. применение ООП.

Представим, что у нас есть система обмена сообщений, что-то типа форума.
Есть пользователи и сообщения. То есть в БД 2 сущности: users, messages
(см. рисунок с ER).

Например, нужно показать сообщение с ID равным "1". В случае публикации БД:
даём запрос по двум таблицам:

SELECT subject, text, user.name, user.surname FROM message
LEFT JOIN user ON message.fk1_login=user.login WHERE message.id=1';

2) Полученный результат в HTML и дело сделано.

В случае с моделью(см. рисунок с диаграммой классов):
1) Создаём экземляр класса сообщения с идентификтором "1"
2) Создаём экземпляр класса пользователя, используя свойство объекта
сообщения

"userLogi_message = new Message(1)
_user = new User(_message.userLogin)n".

Вытаскиваем у объектов _message и _user нужные свойства,
обёртываем в HTML, посылаем клиенту.

При этом при создании экземпляров классов "User" и "Message"
произойдут два запроса(в конструкторах объектов):

1) SELECT subject, text, fk1_login FROM message WHERE id=1;
2) SELECT name, surname, login FROM user WHERE login='soul';

Рисунок 1 - ER-диаграмма

Плюсы и минусы на первый взгляд.

1 случай:
+ высокая скорость(нужен один сложный запрос)
- под каждое представление необходимо формирование своего SQL-запроса

2 случай
+ работаем с объектами модели, а не с БД, что ближе к естественному мышлению
- низкая скорость(происходит несколько простых запросов к БД)


Первый случай, является так называемой публикацией БД в Web,
подходит для небольших задачь.

Второй случай позволяет думать в объектно-ориентированном стиле,
строить более сложные системы.

Рисунок 2 - Диаграмма классов

Добавим в систему возможность объеденения пользователей в группы.
Соотв. в БД появляется сущность "group", а в классовой модели класс "group"
с методами "addUser" и "removeUser" для добавления и удаления
пользователей в группу.

Выводим сообщение c идентификатором "1", а так же
указываем имя, фамилию пользователя и группу, к которой он пренадлежит.

Рисунок 3 - Развитее системы, ER-диагарамма

1. Без объектов модели:
select subject, text, user.name, user.surname, group.name FROM message

LEFT JOIN user ON message.fk1_login=user.login
LEFT JOIN `group` ON user.fk1_group_id=group.id WHERE message.id=1;

2. Через объекты:

_message = new Message(1)
_user = new User(_message.userLogin)
_group = new Group(_user.groupId)

Все нужные нам данные находятся в трёх объектах.

Gри создании экземпляров классов "User", "Group" и "Message"
произойдут три запроса(в конструкторах объектов):

1) SELECT subject, text, fk1_login FROM message WHERE id=1;
2) SELECT name, surname, login FROM user WHERE login='soul';
3) SELECT name FROM `group` WHERE id=1;

Рисунок 4 - Развитее системы, диаграмма классов

Наибольший интерес представляет собой построение самой системы.
На рисунке попытка изобразить из чего состоят разные компоненты системы MVC.

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

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

Рисунок 5 - Архитектура системы

Переход к сервис-ориентированной архитектуре.

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

Рисунок 5 - Сервис-ориентированная архитектура