Смотрите -> http://www.ototsky.mgn.ru/it/presentatio...

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

Так вот, сложилось устойчивое мнение, что огород из нескольких физических уровней городится не потому, что это надо, а потому что какой-то "гуру" сказал. В итоге между экраном конечного пользователя и запрашиваемыми им данными образуется нехилая прослойка, которая на 90% занята перекачиванием исходной информации из одного формата представления в другой: бесконечные сериализации и десереализации, передача XML, дергание за веб-службы... С учетом, например, обновления части экрана по изменению каких-то данных в другой его части эти мытарства умножаются в разы. Растет время отклика системы. Пользователь нервничает и справедливо обвиняет в этом программистов.

Прежде чем городить огород честно задайте себе вопрос: для чего нужен вот этот данный конкретный слой. Скажем, слой WCF для доступа к объектам может быть нужен, если ваш клиент "умный" и "толстый", но работать нужно только по HTTP. А если это приложение ASP.Net, то поищите пути сократить путь (тавтология) информации от источника к пользователю и обратно.

В конце концов, архитектура служит для эффективной реализации системы, а не для вовлечения в команду очередной партии "троешников" на добавляемый слой для освоения бюджета.

И еще. Подход разработки "от модели" позволяет генерировать все эти слои бездельников без участия человека.

От редактора. Статья является объединением нескольких писем автора (А. Скрыпника) в конференцию fido7.su.oop. В ней описана реализация ядра информационной системы, основанная на принципах "кубиков" и моделирующей графической среды. Кроме технологической конкретики сделана попытка раскрыть архитектуру построения подобных систем. Насколько удачно - судить вам, мое позитивное отношение уже выражено самим фактом публикации на сайте.

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

В предыдущей части статьи мы определили основные требования к нашей реализации и создали в первом приближении концептуальную модель данных ядра АИС.

А сейчас рассмотрим пример реализации концепции на базе СУБД PostgreSQL (по-русски читается как «постгрес»).

Вступление

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

Несколько ссылок на интересные, на мой взгляд, дискуссии в ФИДО (для просмотра, возможно, потребуется регистрация в google). Темы поднимаются в виде последовательности писем и реплик на них.

Введение

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