В догонку к предыдущему посту. Возьмем тот же самый MVC. Очень хороший паттерн, безусловно. Но разве Model, View и Controller – единственные части, которые стоит разделять? Вот, например, список уровней веб-приложения, которые, по-хорошему, должны быть четко разделены:
1) Оформление (html, css, js-эффекты)
2) Разметка (html, css)
3) Статическое содержимое (html, message bundles)
4) Динамическое содержимое (html + forms)
5) Связь клиент-сервер (plain http, ajax)
6) Система генерации контента (шаблоны, jsp, whatever)
7) Навигация (action dispatch, page flow)
8) Конверсия
9) Валидация
10) Обработка событий
11) Доступ к объектам-исполнителям (jndi, spring beans, всевозможные ioc-контейнеры, итд)
12) Объекты-исполнители операций
13) Манипуляция данными (plain jdbc, ejb, hibernate)
14) Доступ к данным (jdbc drivers, соединение с БД)
15) Схема хранения данных и операции с данными, реализованные на уровне БД (таблицы, constraints, хранимые процедуры)
Почему же при описании фремворков и других решений обычно говорят только о трех уровнях? На мой взгляд, MVC сам по себе – это слишком большое упрощение, чтобы использовать его как полноценную основу для проектирования или описания ПО. С другой стороны, для начинающих программистов разделение трех уровней – неплохое упражнение в анализе.
Пост вызван абзацем из книги Core JSF в стиле “а вы знаете, JSF тоже построен по MVC!”.
180
В догонку к предыдущему посту. Возьмем тот же самый MVC. Очень хороший паттерн, безусловно. Но разве Model, View и Controller – единственные части, которые стоит разделять? Вот, например, список уровней веб-приложения, которые, по-хорошему, должны быть четко разделены:
1) Оформление (html, css, js-эффекты)
2) Разметка (html, css)
3) Статическое содержимое (html, message bundles)
4) Динамическое содержимое (html + forms)
5) Связь клиент-сервер (plain http, ajax)
6) Система генерации контента (шаблоны, jsp, whatever)
7) Навигация (action dispatch, page flow)
8) Конверсия
9) Валидация
10) Обработка событий
11) Доступ к объектам-исполнителям (jndi, spring beans, всевозможные ioc-контейнеры, итд)
12) Объекты-исполнители операций
13) Манипуляция данными (plain jdbc, ejb, hibernate)
14) Доступ к данным (jdbc drivers, соединение с БД)
15) Схема хранения данных и операции с данными, реализованные на уровне БД (таблицы, constraints, хранимые процедуры)
Почему же при описании фремворков и других решений обычно говорят только о трех уровнях? На мой взгляд, MVC сам по себе – это слишком большое упрощение, чтобы использовать его как полноценную основу для проектирования или описания ПО. С другой стороны, для начинающих программистов разделение трех уровней – неплохое упражнение в анализе.
Пост вызван абзацем из книги Core JSF в стиле “а вы знаете, JSF тоже построен по MVC!”.