Добрый день!
Хотел бы обсудить пару интересующих меня моментов, касающихся проектирования бизнес-логики приложения.
Для примера возьму существующее веб-приложние (asp.net, хотя вряд ли технология тут имеет значение) среднего масштаба (~70 таблиц в БД, планируются большие объемы данных, десятки, позже сотни пользователей). Имеются выделенные слои UI, BLL, DAL. Имеют место интеграция с другими системами (веб-сервисы, выгрузка-загрузка из файлов).

На текущий момент я вижу несколько основных проблем:
1) Жизненный цикл бизнес-объекта. Он может быть создан, изменен или удален через: UI вручную (причем несколькими способами), автоматически в рамках какого-то другого действия, "импортирован" из файла. Эти операции затрагивают другие объкеты - они могут быть созданы, изменены или удалены вместе с текущим.
Проблема: Ее совсем понятно, как на уровне классов организовать работу с таким объектом. В данный момент имеется класс-помойка, в котором есть группы действий вроде AddFromUI, AddFromFile,..., UpdateFromUI, UpdateSomeStatus,... И еще куча дополнительных методов. Получается, слишком большой класс. Можно было бы разделить его на несколько классов, но тогда эти классы были бы очень сильно связаны между собой.
2) Поиск набора объектов - ну очень хочется сделать какую-то абстракцию (вроде IFinder<T>), однако, ищутся разные объекты по разным полям...
Проблема: Куча классов-"поисковиков" (примерно равная кол-ву разных типов бизнес-объектов), не имеющих ничего общего между собой, в результате сильно повышается зависимость BLL от DAL.
3) Валидация объекта при создании из UI. Основная валидация находится в BLL, однако, для удобства пользователя иногда нужно делать "быструю" валидацию средствами JavaScript (например, у объекта есть 2 поля-даты, одно должно быть всегда больше другого, или поле должно соответствовать регулярному выражению - пользователь ввел, сразу видит ошибку без лишних нажатий кнопок).
Проблема: Дублирование кода при простой реализации, не очень оправданное усложнение при попытке сделать через Ajax + валидация в BLL.
4) Вывод разных списков объектов - asp.net предлагает удобное решение с поддержкой сортировок, paging и т.п., в моем случае это все делается средствами СУБД
Проблема: в результате имеем тут совсем не объектно-ориентированный подход, без использования бизнес-объектов. По сути BLL в этом случае нужен только чтобы формально не делать связку UI-DAL. Как результат - повсеместный ввод названий полей БД вручную, необходимость иногда писать "хитрые" запросы чтобы вывести какие-то вычислимые данные.

Прошу всех высказывать свои советы по тому, как вам приходилось разрешать подобные проблемы (или какие еще проблемы бывали)

kolobok0я возможно не до конца чуствую вашу специфику, но кмк бизнес объекты - самые статичные сущности в проекте...


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

Почему-то, всех сразу захватил только первый пункт исходного поста... Наверное, тут действительно имеет место "плавно превращается в кошку пьющую молоко". Т.е. имеет место сущность, явно используемая для разных целей в зависимости от контекста.
А как вы поступаете с остальными пунктами?

Petro123,
Имеется ввиду БЛ на апп сервере.