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

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

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

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


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

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

не вижу причин по которым она там должна быть. например если она там вся — то как обеспечить расштабирование в ширь ?

В люом случае я там ниже писал про возможность подработки апликешен сервером. Если вы считате это достоинством это нормально.

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

MC>Если весь код сосредоточне в приложухе, то ломающие изменения в БД значительно реже.
если в базе происходит изменения то круд наверное первое что меняется — в смысле один из методов, то ли create, то ли read или update.
как на меня, всегда, если меняется база — это как правило изменение алгоритмов работы — так как это должно быть учтено в алгортомах иначе зачем вводить новые данные (не всегда но как правило изменение баззы это результат ввода новых данных в систему), хотя обратное утверждение не всегда справедливо, т.е. алгоритмы могут менять без изменений структуры данных... но не суть.
MC>Соотвевеноо миграции меджу версиями всей системы проще.
Более того у вас появляеться возможность работы двух версий приложухи с одним сервером БД.
сомнительная выгода ? второе приложеие — это другая логика иначе можно использовать логику первого приложения, а другая логика это все же другая структура, хотя тоже не факт...

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

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

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

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

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

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


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

MC>Мои ответы это не более как попытка хинтов.
и вам за это спасибо

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

и так в результате нашей бесседы, с моей точки зрения, единственным "обективным" аргументом за реализацию CRUD только средствами сашрпа — это то что код будет в одной сборке с БЛ, хотя не факт, и это даст возмонрость не заботиться за совместимость кода на шарпе с хранимками на сиквеле... преимущество илозорное, но все же принять можно ... еще что-то ? у коговто есть еще какие-то за и против ?