Здравствуйте, Mike Chaliy, Вы писали:

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


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

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

я не тупо перечу, я пытаюсь понять...

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


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


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

MB>>потому как вопрос в той или иной мере становиться в плоскости где именно они должны быть определены, а сократить их количество навряд ли получиться или ... есть варианты?
MC>Почему же, в коде у вас все возможности кода. Там не надо писать 1000 методов. Надо написать два один для маркировки второй для физического удаления.
не понял: поясню свою мысль, а вы свою плиз: моя мысль в том, что имея бизнес сущность, и определяя CRUD для нее(4 операции) что на стороне сиквела, что на стороне шарпа я все равно определяю 4 операции, и в данном случае не имеет значения как производиться удаления...

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

вообще вопрос был использовать ли ХП для реализации CRUD при использовании EF. т.е. бизнес логика вынесена в отдельный слой, котрый не хоститься в хранилище (на SQL сервере в частности). и конечно можно обсудить например где вообще хостить слой бизнес логики — отрывать его от SQL сервера или нет... мне довелось встречаться с командой, котрая не признавала ничего другого как размещения всей бизнес логики в Oracle и все вопросы о сопровождении, о распределении нагрузки и т.д. овтечались просто — оракл это умеет — он распределяет и т.д. хотя приколно что я был приглашен для потому для борьбы со возросшей сложностью приложения но это не суть.

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