MC>Все зависит от архитектуры

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

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

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

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

MC>- в другом случае если надежда тока на скуль сервер, то потдержку 4000 очень легко автоматизировать. Любой генератор српавляеться с этим на ура. Простейшие операции описываються очень простыми языками.
т.е. если я правильно понял Вас, то Ваш критерий таков: если бизнес логика вся на стороне SQL сервера и в хранимых процедурах, то и CRUS должен быть в хранимках — но ведь это и понятно. потому как какой смысл делать CRUD процедуры в шарпе если всябизнес логика в сиклвел сервере — это выглядит не логично. скорее всего я не внятно изложил вопрос. я спрашивал мнение вот о чем — есть слой бизнес логики определенный на шарпе — пусть в одном или нескольких модулях. есть бизнес сущности — они сгенерированы при помощи EF. так или иначе есть необходимость создавать бизнес сущности, изменять и удалять. вопрос: стоит ли использовать хранимые процедуры при CRUD операциях для этих сущностей или все же выполнять это все в коде на шарпе... а поскольку например стандартное удаление предполагает реальное удаление, то нужно везде где будет удаляться объект писать код по переводу ее (бизнес сущности) в состояние уделенная. конечно эту активность можно вынести в процедуру и использовать ее по необходимости, как вариант, а может и просто хранимку вызвать, тем более что какая тогда разница что хранимка, что код — все равно процедур будет 1:4 и т.д. вопрос в подходах, объективных критериях того как можно оценить, что лучше вообще или в данном конкретном случае в частности ...
т.е. все зависит от архитектуры — это не тот случай — именно что от чего зависит и хотелось бы по возможности объективно оценить
за ответ спасибо — было интересно.