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

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

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


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

MC>>За БЛ.
MC>>1) Логика в одном месте;
MB>и да и нет — в одном месте в распределенной системе теряет значимость... а вот вынос CRUD в хранимки поможет освободить сервер БЛ.
Тогда по идее вся БЛ должна быть в СКУЛЬ серевере. В люом случае я там ниже писал про возможность подработки апликешен сервером. Если вы считате это достоинством это нормально.

MC>>2) Дешевле потдерживать и версионировать;
MB>сомнительно — механизм версионности что для шарпа, что для сиквала одна, например тот же VSS.
Я не имел ввиду версионирование кода. Я имел ввиду версионирование компонентов. У вас есть два компонента ваша приложуха и БД. По идее вы всегда должны трекать совместимость версий этих компонент. Если весь код сосредоточне в приложухе, то ломающие изменения в БД значительно реже. Соотвевеноо миграции меджу версиями всей системы проще. Более того у вас появляеться возможность работы двух версий приложухи с одним сервером БД.

MC>>3) нема дублирования кода;
MB>это зависит как напишите, никто не мешает писать процедуры без дублирования кода.
попрбуйте, как мне видиться реализация на СКУЛЕ
1) Хранимка для кадой сущности (куча простныей кода);
2) В каждой хранимке так или иначе код или по удалнию или по маркировки (реальное дублирование).
реализация на БЛ
1) Базовый репозитарий для удаляемых
2) Базовай репозитарий для маркируемых
или
1) Те что должны маркироваться, должны быть как то отмаркированы(атрибутом или интерфесом).

MB>а то создается впечатление что в сам язык SQL введен механизм дублирования кода
Так и есть, одного из решений по борьбе с дублированием как наследования там точно нема. Да и других абстракий тоже.

MC>>4) тестируемость;
MB>мне удобней тестировать шарп плюсы, но не сиквел, а ребятам котрые пишут под сиквел плевать на мой шарп они на сиквеле живут и тестирваться для них там то же что и мне на шарпе... хотя справедивости ради я пользуюсь VS по этому мне пошаговое тестирование и на сиквеле не проблема то особо
Для тестирования хранимки нужен енваирмент(и сама БД и еталонные данные), для тестирования БЛ достачно емуляции оного. Хотя никто не спорит, если у команды уже наработанные техники для работы с БД то почему бы и нет.

MC>>5) Меньше кода, меньше инфраструктуры;
MB>меньше кода это если вы хотите интегралы считать а если запрос сделать то вопрос еще спорный потому как сиквел как раз для этого и заточен... меньше инфраструктура — не знаю что вы подразумеваете под этим.
Например для потжержки 4000 процедур нудны какието тулзы. Для БЛ достаточно того что есть.

MC>>6) Возможность одновременных и маркировки и физического удаления для каждой сущности.
MB>ну это уже чать бизнес логики — т.е. особбености бизнес задачи, и на сиквеле можно это сделать не с меньщей эфектифностью — передал ключ проапдейтил или удалил, в зависимости от логики.
А можно туда еще передать флаг кторый будет обозначать надо ли отправить почту... Вобщемто для меня это разные бизнес операции. И я не сторонник обьеденять необеденяемое и впихивать невпихуемое. Тем более что не совсем понятно как вы это обьясните ЕФ...

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

MC>>2) Возможность подработки апликешен сервером (доступ из нескольких приложух);
MB>доступ из нескольких может быть реализовн через сервис — и мне это в некотрых моментах даже больше нравиться.
Вы в первом ответе за БЛ написали другое.


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