Правила простроения бизнес-логики

Для построения бизнес-логики используется иерархическая модель функциональных элементов.
То есть базовым элементом бизнес-логики является функция - компонент, которая реализована с помощью
объекта класса Command с методом Exec, это типичный шаблон проектирования Command

Что же вы совсем языки пооткусывали, господа?

Тема этой ветки тоже относится скорее к теме "идеальной БД". Тоже обсуждение концепций, но уже использования браузера для работы с БД, как middleware между человеком и сервером. Основной постулат: браузер есть идеальный клиент идеальной БД. Для этого ему нужна небольшая JS-библиотека, подгружаемая прозрачно для пользователя.

Здравствуйте. Как-то настораживает, что здесь просто МЕРТВАЯ тишина, но, возможно, это и к лучшему. Я хотел бы обсудить концепции построения моделей и баз данных, сформулировать требования к идеальной БД. По всей цепочке: от ядра до конечного пользователя. Но только концепции - иначе мгновенно утонем.

Привет. Вот что пишут

http://www.cnews.ru/news/top/index.shtml?2011/11/17/464954

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

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

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

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

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

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

С трудом отыскал и даже скопировал локально. Читать архив здесь.

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

В условно называемом "классическом" проектировании БД выделяют концептуальную, логическую и физическую модели данных. Однако, многие CASE-средства, например, ERwin или PowerDesigner оперируют только двумя моделями в своей терминологии: концептуальной/логической и физической.

Чтобы не запутаться в подобной ситуации воспользуйтесь следующей табличкой соответствия.