Здравствуйте, Monkey-Bee, Вы писали:


MC>>- например если есть бизнес слой то наверное принимать решение по всем операциям (включая удаление или пометку) должен он.
MB>в любом случае про удаления объектов решает бизнес логика — или если точнее это одна из активностей в рамках выполняемого бизнес логикой процесса. я говорю о том где и как должен быть определен код этой активности, это может быть просто db.DeleteObject(object); или изменение статуса объекта еще в шарп коде или же это может быть определено в хранимой процедуре которая вызывается на стороне БЛ но уже сама в сиквеле определяет как конкретно происходит удаление, как пример я сказал — не реальное удаление а изменение статуса. т.е. статус можно менять и в шарп коде а можно в сиквеле — вопрос за и против.

За БЛ.
1) Логика в одном месте;
2) Дешевле потдерживать и версионировать;
3) нема дублирования кода;
4) тестируемость;
5) Меньше кода, меньше инфраструктуры;
6) Возможность одновременных и маркировки и физического удаления для каждой сущности.

За СКУЛЬ
1) Гарантия;
2) Возможность подработки апликешен сервером (доступ из нескольких приложух);
3) Дополнительный слой абстракции.


MC>>Тогда вобщемто вся логика в хранимках становиться ненужной и дублирующей.
MB>а не нужно ее дублировать — ее можно разнести так чтобы избежать связности, чтобы повысить производительность или облегчить сопровождение продукта и т.д.
Если она уже есть на клиентской стороне, то куда еще ее можно разнести?

MC>>В таком случае быстрее всего можно принять решение что потдержка 4000 процедур это слишком дорого.
MB>как вариант да, а когда можно решить что 4000 это не слишком дорого?
Например когда есть рекваирмент логирования на уровне БД или когда есть рекваирмент секурити тримминга на уровне БД. Всякое бывает.

MB>потому как вопрос в той или иной мере становиться в плоскости где именно они должны быть определены, а сократить их количество навряд ли получиться или ... есть варианты?
Почему же, в коде у вас все возможности кода. Там не надо писать 1000 методов. Надо написать два один для маркировки второй для физического удаления.

Я бы выбрал все в БЛ как более простое решнение. В случае необходимости добавил бы хранимки, но тока в случае острой необходимости. Ваш пример такой необходимостью не являеться.