с одной стороны вопрос сферического коня в вакууме, а с другой — проза жизни.

интересно было бы услышать мнения за и против использования хранимых процедур в CRUD (по одной на операцию). с учетом использования ADO.Net Entity Framework.

с одной стороны 1000 таблиц 4000 процедур, "сложность" сопровождения, время написания и т.д. с другой стороны — удобство управления процессом удаления, например некоторые бизнес объекты не должны быть удалены с базы вообще, а вместо этого их состояние меняется на удаленный, логирование измененией и т.д. и это удобно, однажды описав поведение в ХП, использовать его в других случаях.

если кто имеет какие-то критерии оценки "что такое хорошо и что такое плохо" — было бы интересно услышать.

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

MB>с одной стороны вопрос сферического коня в вакууме, а с другой — проза жизни.

MB>интересно было бы услышать мнения за и против использования хранимых процедур в CRUD (по одной на операцию). с учетом использования ADO.Net Entity Framework.

MB>с одной стороны 1000 таблиц 4000 процедур, "сложность" сопровождения, время написания и т.д. с другой стороны — удобство управления процессом удаления, например некоторые бизнес объекты не должны быть удалены с базы вообще, а вместо этого их состояние меняется на удаленный, логирование измененией и т.д. и это удобно, однажды описав поведение в ХП, использовать его в других случаях.

MB>если кто имеет какие-то критерии оценки "что такое хорошо и что такое плохо" — было бы интересно услышать.

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

— например если есть бизнес слой то наверное принимать решение по всем операциям (включая удаление или пометку) должен он. Тогда вобщемто вся логика в хранимках становиться ненужной и дублирующей. В таком случае быстрее всего можно принять решение что потдержка 4000 процедур это слишком дорого.

— в другом случае если надежда тока на скуль сервер, то потдержку 4000 очень легко автоматизировать. Любой генератор српавляеться с этим на ура. Простейшие операции описываються очень простыми языками.

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

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

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

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

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

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

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


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

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

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


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

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

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

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

Здравствуйте, 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. а не вопросом где вообще держать бизнес логику...

Здравствуйте, 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>доступ из нескольких может быть реализовн через сервис — и мне это в некотрых моментах даже больше нравиться.
Вы в первом ответе за БЛ написали другое.


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

Здравствуйте, 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 только средствами сашрпа — это то что код будет в одной сборке с БЛ, хотя не факт, и это даст возмонрость не заботиться за совместимость кода на шарпе с хранимками на сиквеле... преимущество илозорное, но все же принять можно ... еще что-то ? у коговто есть еще какие-то за и против ?

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

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

Выбрать заранее и правильно может не получиться.

Могу посоветовать действовать так:
1)Используете встроенные возможности EF пока получается
2)Если нужно дополнить логику CRUD, например сохранение имени пользователя системы, изменяющего запись, то используйте partial методы объектов EF.
3)Если надо переопределить логику CRUD, например пометка IsDeleted вместо удаления, то создавайте в СУБД вьюхи + instead of триггеры.
4)Если вам нужна очень сложная логика CRUD, то создавайте хранимки

Насколько я понимаю, если делать запрос вида

select * from sp_getsomething where <что-нибудь>
-- где sp_getsomething - хранимка

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

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

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

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

G>Выбрать заранее и правильно может не получиться.
а хотлеось бы вообще-то думаю что обсудив все объективные за и против — можно иметь шпору на дудущее, хотя сейчас я как раз работаю над одним таким проектом.

G>Могу посоветовать действовать так:
G>1)Используете встроенные возможности EF пока получается
разумно, заем пользоваться другой технологией если, то что есть удовлетворяем. но иногда можно и использовать другую технологию, если она привнесет больше пользы чем будут недостатки связанные с ее использованием. короче, это скорее не аргемент за или против а хороший стиль..ю и это принимается.
G>2)Если нужно дополнить логику CRUD, например сохранение имени пользователя системы, изменяющего запись, то используйте partial методы объектов EF.
это реализация пункта 1) и как уже говорилось принимается.
G>3)Если надо переопределить логику CRUD, например пометка IsDeleted вместо удаления, то создавайте в СУБД вьюхи + instead of триггеры.
со вьюхами понятно — отображаем там тех кто у котрых IsDeleted=false. а вот с тригерами не совсем ... во первых тригеров не люблю — считаю их парашутом если при проектировании не учли то в тригирах отыграемся ну а если серьезно, то если заранее изветсна логика то лучше ее сразу вынести в рамки процесса а не в тригера... по этому если не против уточните.
G>4)Если вам нужна очень сложная логика CRUD, то создавайте хранимки
G>Насколько я понимаю, если делать запрос вида

G>

G>select * from sp_getsomething where <что-нибудь>
G>-- где sp_getsomething - хранимка
G>

G>То оптимизатор и индексы работать не будут, и сервер сначала подтянет все записи, возвращенные процедурой, а потом будет их фильтровать.
а почему очень сложная логика CRUD процедур, то в хранимки? не понятно очень сложную логику легче реализовать как раз не стороне шарпа ... поясните плиз для тех кто в танке
а вообще, Ваш подход понятен и и приемлем. какие-то еще за или против?

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

G>>3)Если надо переопределить логику CRUD, например пометка IsDeleted вместо удаления, то создавайте в СУБД вьюхи + instead of триггеры.
MB>со вьюхами понятно — отображаем там тех кто у котрых IsDeleted=false. а вот с тригерами не совсем ... во первых тригеров не люблю — считаю их парашутом если при проектировании не учли то в тригирах отыграемся ну а если серьезно, то если заранее изветсна логика то лучше ее сразу вынести в рамки процесса а не в тригера... по этому если не против уточните.
Триггеры на вьюхе позволяют работать с ней как с таблицей. При переходе на вьюхи с триггерами код приложения менять не придется. Кроме того триггеры позволяют сократить количество написанного SQL кода. Например в случае пометки удаленных записей флагом IsDeleted достаточно будет созать вьюху и написать один триггер на удаление, если делать с помощью процедур, то надо писать все 4 штуки.

G>>4)Если вам нужна очень сложная логика CRUD, то создавайте хранимки
MB>а почему очень сложная логика CRUD процедур, то в хранимки? не понятно очень сложную логику легче реализовать как раз не стороне шарпа ... поясните плиз для тех кто в танке
Я имею ввиду именно логику связанную с операциями CRUD. Например для выборки требуется танцы с курсорами, а вставка осуществляется каким-нибудь хитрым образом. Такие операции лучше делать хранимками. Но такие случаи встречаются очень редко.

Вся бизнес-логика должна быть в коде приложения, а не в БД.

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

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

3)Если надо переопределить логику CRUD, например пометка IsDeleted вместо удаления, то создавайте в СУБД вьюхи + instead of триггеры.
MB>>со вьюхами понятно — отображаем там тех кто у котрых IsDeleted=false. а вот с тригерами не совсем ... во первых тригеров не люблю — считаю их парашутом если при проектировании не учли то в тригирах отыграемся ну а если серьезно, то если заранее изветсна логика то лучше ее сразу вынести в рамки процесса а не в тригера... по этому если не против уточните.
G>Триггеры на вьюхе позволяют работать с ней как с таблицей. При переходе на вьюхи с триггерами код приложения менять не придется.

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

G>>>Кроме того триггеры позволяют сократить количество написанного SQL кода.
я так смотрю, что пока мне удается уйти, без проблем, от использования сиквела... по этому весь код получается на шарпе, наверное это не плохо

G>>>Например в случае пометки удаленных записей флагом IsDeleted достаточно будет созать вьюху и написать один триггер на удаление, если делать с помощью процедур, то надо писать все 4 штуки.

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

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

я кстати думаю не переутежеляю ли я CRUD. но посмотрим... но все равно нужно будет делать процесс удаления и само удаления это "разные" вещи...

G>>>4)Если вам нужна очень сложная логика CRUD, то создавайте хранимки
MB>>а почему очень сложная логика CRUD процедур, то в хранимки? не понятно очень сложную логику легче реализовать как раз не стороне шарпа ... поясните плиз для тех кто в танке
G>Я имею ввиду именно логику связанную с операциями CRUD. Например для выборки требуется танцы с курсорами, а вставка осуществляется каким-нибудь хитрым образом. Такие операции лучше делать хранимками. Но такие случаи встречаются очень редко.

G>Вся бизнес-логика должна быть в коде приложения, а не в БД.

есть какие-то против ? может я не заметил подводных течений ?

Именно с EF использовать механизм кодогенерации sql-ных CRUD-процедур ощутимо менее приятно, чем с каким-нибудь BLToolkit. Особенно если есть желание поменьше возиться ручками. То есть сгенерировать-то их можно, но появляется как минимум проблема генерации секций FunctionImportMapping в edmx-файле (в противном случае придется маппить вручную в EDM-дизайнере, что при определенных обстоятельствах может помрачить и без того нестабильный рассудок разработчика). В настоящий момент у нас используются sql-ные CRUD только для тех случаев где без них не обойтись.

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

MB>с одной стороны вопрос сферического коня в вакууме, а с другой — проза жизни.

MB>интересно было бы услышать мнения за и против использования хранимых процедур в CRUD (по одной на операцию). с учетом использования ADO.Net Entity Framework.

MB>с одной стороны 1000 таблиц 4000 процедур, "сложность" сопровождения, время написания и т.д. с другой стороны — удобство управления процессом удаления, например некоторые бизнес объекты не должны быть удалены с базы вообще, а вместо этого их состояние меняется на удаленный, логирование измененией и т.д. и это удобно, однажды описав поведение в ХП, использовать его в других случаях.

MB>если кто имеет какие-то критерии оценки "что такое хорошо и что такое плохо" — было бы интересно услышать.

Про сферического коня. У вас действительно 1000 таблиц? Т.е в терминах EF у вас порядка 1000 (если есть наследование — будет чуть поменьше) самостоятельных типов сущностей? Я даже боюсь прикинуть стоимость инициализации и поддержки такой модели... Чтой-то тут не то...

Давайте опустимся на землю. У вас одноразовый проект? Сколько он должен жить? Будет ли интеграция? Насколько критична безопасность? Пока вы сами себе не ответите — беседовать не о чем.

Если вы твёрдо решились на использование EF — учтите, что тов. разработчики EF, такое впечатление вообще рассматривают SP как легаси (в подтверждение: "The EF team on several occasions said that “Nobody is building an application using stored procedures and straight ADO anymore.”", [http://www.stephenforte.net/PermaLink,guid,bc1bc043-3cdc-4ac2-8b46-3c72ad1d61cf.aspx]). Так они дойдут до того, что и СУБД — тоже легаси

Если собираетесь сделать нормальную прослойку из ХП — то вам EF будет только мешать, чесслово. Особенно когда дойдёт до загрузки связанных сущностей [http://blogs.msdn.com/bethmassi/archive/2008/12/10/master-details-with-entity-framework-explicit-load.aspx] или хардкорной оптимизации. Учитывайте также, что EF не совсем подходит для пакетного (или отсоединённого — как больше нравится) режима работы или nTier.

В общем, если у вас одиночное приложение, вы не собираетесь интегрироваться с другими системами или прикручивать отчёты — вэлкам к EF. В противном случае я бы сначала подумал.

Удачи

P.S. Data Consistency если что, проще обеспечивать через триггеры и ограничения. Все остальные способы, пока вы не закроете прямой доступ к данным, работать не будут.

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

S>Если собираетесь сделать нормальную прослойку из ХП — то вам EF будет только мешать, чесслово. Особенно когда дойдёт до загрузки связанных сущностей [http://blogs.msdn.com/bethmassi/archive/2008/12/10/master-details-with-entity-framework-explicit-load.aspx] или хардкорной оптимизации.

Чем прослойка из ХП нормальнее Updateable View или View+Triggers?
Интересуют именно CRUD операции.

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

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

MB>>с одной стороны вопрос сферического коня в вакууме, а с другой — проза жизни.

MB>>интересно было бы услышать мнения за и против использования хранимых процедур в CRUD (по одной на операцию). с учетом использования ADO.Net Entity Framework.

MB>>с одной стороны 1000 таблиц 4000 процедур, "сложность" сопровождения, время написания и т.д. с другой стороны — удобство управления процессом удаления, например некоторые бизнес объекты не должны быть удалены с базы вообще, а вместо этого их состояние меняется на удаленный, логирование измененией и т.д. и это удобно, однажды описав поведение в ХП, использовать его в других случаях.

MB>>если кто имеет какие-то критерии оценки "что такое хорошо и что такое плохо" — было бы интересно услышать.

S>Про сферического коня. У вас действительно 1000 таблиц? Т.е в терминах EF у вас порядка 1000 (если есть наследование — будет чуть поменьше) самостоятельных типов сущностей? Я даже боюсь прикинуть стоимость инициализации и поддержки такой модели... Чтой-то тут не то...
пока проет на стадии проектирования, т.е. там нет всей 1000 я даже не могу сказать что там будет их ровно 1000 но что это число соотносится с реальным числом бизнес сущностей которые буду в результрующей информационной системе так это точно ... это не число таблий как таковых это число бизнес сущностей модели (но оно стримиться к числу таблиц, так как почти все эти сущности так или иначе должны быть персистенты). поскольку разрабатываемая система это набор взаимодействующих подсистем котроые работают в рамках одной модели предметной области, то сущностей будет много — впринципе в результате это система призвана заменить существующий зоопарк и дублирование того что есть... а так же позволить работать в едином пространстве бизнес сущностей. т.е. не буду вдаваться в подробности, как я напимсал это не пример hello world — а корпоративная информационная система.

S>Давайте опустимся на землю. У вас одноразовый проект? Сколько он должен жить? Будет ли интеграция? Насколько критична безопасность? Пока вы сами себе не ответите — беседовать не о чем.
давно уже на земле — проект совсем прибил к ней относительно одноразовости проекта — я не совсем понял что вы имеете в виду — у меня все все проекты одноразовые они могут быть схожы в чем то или нет, поскольку проект не написание утилиты, а корпоратвиной ис, то отличительных особеностей значительно больше чем при проекте написании интеренет магазина, необходимо учитывать как специфику бизнеса компании, ее культуру, сложившиеся бизнес процессы и готовности их менять, наличие существующих ис и многое другое — как правило, по моему опыту, это меняется от компании к компании. по этому в этом случае ис разрабатывается разово, а сопроваждается и поддердивается долго.

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

S>Если вы твёрдо решились на использование EF — учтите, что тов. разработчики EF, такое впечатление вообще рассматривают SP как легаси (в подтверждение: "The EF team on several occasions said that “Nobody is building an application using stored procedures and straight ADO anymore.”", [http://www.stephenforte.net/PermaLink,guid,bc1bc043-3cdc-4ac2-8b46-3c72ad1d61cf.aspx]). Так они дойдут до того, что и СУБД — тоже легаси
скорее всего что решел твордо ) (в крайнем случае всешда можно работать в старом стиле )так как прототип пишеться уже с использованием EF и соответсвено сотрудников нужно этому обучать или набирать новых с учетом знаний и т.д.

спасибо всегда интересно услышать мнение разаработчика технологии, а то иногда получается, что они что-то пишут потом кто-то галюцинирует на них, а нам как конечным пользователям приходиться уже галюцинировать на галюцинации (утрирую)

S>Если собираетесь сделать нормальную прослойку из ХП — то вам EF будет только мешать, чесслово. Особенно когда дойдёт до загрузки связанных сущностей [http://blogs.msdn.com/bethmassi/archive/2008/12/10/master-details-with-entity-framework-explicit-load.aspx] или хардкорной оптимизации. Учитывайте также, что EF не совсем подходит для пакетного (или отсоединённого — как больше нравится) режима работы или nTier.

я, кстати, нигде так и не встречал нормального описания того, как должен использоваться или как планируется использоваться EF в nTire приложениях... возможно, потому что он никак и не предполагается использоваться там или плохо искал но как по мне, такие вещи, если они планируются разработчиками технологии, наверняка не умалчиваются и проходят красной нитью — как следствие напрашивается вывод — что-то не совсем понятное с EF при nTire. а то как происходит работа с отдетечиными объектами, наталкивает на мысль что разработчики технологии планировали что все изменения будут происходить только в рамках контекста, но передача конеткста между слояими уже дурной тон а между уровнями .... )... остается только один выход создавать сервисы и делать все изменения в рамках их интерфейсов, но тогда вопрос: а чем здесь EF помогает ? — отвент ничем — а вот чем мешает — могу отвтетить — как минимум тем что необходимо аттачить сущности... а если учесть особенности клиента, например SilverLight то тогда сгенерированные EF сущности не могут использоваться для взаимодействия между слоями логики и представления и в этом случае необходимо создавать DTO или отдавать XML и парсить его на стороне представления — что таоже гимор ... по сравнению использования единогго пространства бинес сущностей.... так же при таком подходе изменения на клиенте могут быть лишь для простых типов а в случае изменеия ссылки (навигации)необходимо пользоваться как уже сказал IP сервиса а это вызов... а как хотелось бы сделать так чтобы получил от сервиса бизнес сущность или несколько, сделал изменения в них — всязи между ними, линки, (всмысле пользователь делает изменения) и всех их отослать на сервер типа сохранить, но с EF такого не будет

S>В общем, если у вас одиночное приложение, вы не собираетесь интегрироваться с другими системами или прикручивать отчёты — вэлкам к EF. В противном случае я бы сначала подумал.
иными словами вы говорите что если это не простой пример с MSDN`а а реальное приложение, то нужно очень сильно задуматься я с вами согласен... ктсати, как-то мне рассказали шутку чем отличается архитектор от разработчика: разработчик, начало проекта. разработчик думает: так, и как бы эту хрень вообще сделать? архитектор, начало проекта: мысли архитектора, так, и каким способом попробовать эту хрень сделать в этот раз так что б не скучно было

S>Удачи

спасибо — это как хороший совет- никогде не помешает

S>P.S. Data Consistency если что, проще обеспечивать через триггеры и ограничения. Все остальные способы, пока вы не закроете прямой доступ к данным, работать не будут.
тригериы я оставлю на потмом — в качестве паращюта. работать с базой и изменять данные все равно нельзя помимо специально для этого сделанного слоя работы с данными, под страхом смертной казни только через сервисы, а сервисы в свою очередь черз слой.

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

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

G>Здравствуйте, Sinix, Вы писали:

S>>Если собираетесь сделать нормальную прослойку из ХП — то вам EF будет только мешать, чесслово. Особенно когда дойдёт до загрузки связанных сущностей [http://blogs.msdn.com/bethmassi/archive/2008/12/10/master-details-with-entity-framework-explicit-load.aspx] или хардкорной оптимизации.

G>Чем прослойка из ХП нормальнее Updateable View или View+Triggers?
G>Интересуют именно CRUD операции.
а я вообще последнее время стал сильно задумываться, а зачем нужны хранимки в CRUD. все можно сделать в рамках бизнес логики на стороне приложения, думаю что использование хранимок определяет сложность бизнес логики, когда при добавлении новой сущности нужно просто воткнуть ее в таблицу тогда все равно что использовать можно и хранимки, а кагда добаление новой сущности запускает процесс, тогда все равно нужно логику писать и чем воткнуть в таблицу резултьтат роли не играет, но поскольку все уже и так в коде пишется, то зачем еще и хранимки сюда добавлять ? хотя ... возможно кто-то имеет другое, обоснованное мнение, потому как у меня это всего лишь ощущения ...

Тааак, чтой-то тут много написали
Давайте я в три приёма отвечу — про ваш проект, про CRUD и БЛ на уровне СУБД и про EF. Поехали.

1) Ваш проект.

А>пока проет на стадии проектирования, т.е. там нет всей 1000 я даже не могу сказать что там будет их ровно 1000 но что это число соотносится с реальным числом бизнес сущностей которые буду в результрующей информационной системе так это точно ... это не число таблий как таковых это число бизнес сущностей модели (но оно стримиться к числу таблиц, так как почти все эти сущности так или иначе должны быть персистенты). поскольку разрабатываемая система это набор взаимодействующих подсистем котроые работают в рамках одной модели предметной области, то сущностей будет много — впринципе в результате это система призвана заменить существующий зоопарк и дублирование того что есть... а так же позволить работать в едином пространстве бизнес сущностей. т.е. не буду вдаваться в подробности, как я напимсал это не пример hello world — а корпоративная информационная система.

Вы знаете, из моего опыта — это будет ОЧЕНЬ большой проект. Я ни разу не сталкивался с тем, чтобы в конкретном приложении — не во всей системе, а в конкретном приложении — использовалось больше пары десятков независимых сущностей, даже десяток — уже много. // Я не беру в расчёт всякие справочники. Вы не сможете запихнуть такой объём в одну модель EF (не, я верю что сможете, но вот пользовать такого динозавра )

ИМХО, у вас в конце-концов получится несколько десятков моделей EF, которые будут частично перекрываться. И вот тут вам грядёт попа. Потому как
а) в разных моделях вам понадобится разный набор атрибутов для одной и той же сущности
б) БЛ в этих моделях будет очень слабо пересекаться.
в) эти два представления должны быть соответствовать одним и тем же данным.
г) Сам доступ к этим данным желательно проводить ч/з обёртки-представления (аудит, контроль доступа и т.п.)

Решать такие пролемы в терминах объектной модели — ещё большая попа. Если интересует — отпишусь подробней, пока оставим.


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

А>будет ли интеграция — на первых порах бедут, в дальнейшем, если это будет целесообразно, будут писаться модули заменяющие старые системы.
А>безопастность довольно критичка по этому планируется испольовать сертификаты.

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

Из последней цитаты следует наличие аппсервера. Поправьте если не прав.

Воот. Видите, проекту ещё жить и жить. А вы уже ограничиваете клиентов одной платформой, да ещё и одним фреймворком. Не, сначала это некритично, но вот потом, когда EF объявят слегка устаревшим (как недавно Linq for SQL)... Здесь я конечно передёргиваю — такая радость наступит очень и очень нескоро — очень уж много на EF поставлено. Но посмотрите, сколько программ умеют ODBC/OLEDB, и сколько — EF. Допустим, когда вам потребуются отчёты, вы с удивлением увидите, что МС умеет свой репортсервер или датасеты, кристал репортс умеет свой формат и слегка произвольные объекты, у остальных вендоров — не лучше. Эксель, допустим — вообще только OLEDB|ODBC // не пробовали аналитику в экселе 2007? очень советую — весчь, если готовить. Если у вас половина систем (не забываем про интеграцию) будет лезть напрямую к СУБД — что вам дают ваши сервисы?

Про одноразовость проекта. Скажите, индивидуальный дух компании так влияет на подсистемы контроля доступа, развёртывания, администрирования? Все эти велосипеды тоже заново пишутся?

Дальше. Сервисы. Что собираетесь использовать? Веб-сервисы в чистом виде или WCF? В любом случае вам потребуется загружать в сервис данные с сервера, применять изменения, переданные клиентом, и отсылать даные обратно. Самостоятельно отслеживать изменения при сериализации EF не умеет. Одно это уже удерживает меня от совместного использования EF и аппсервера.

Безопасность. Как у вас будет проходить авторизация? Где будет разграничиваться разрешения пользователя? На сервисах, или на СУБД? Как будет защищаться соединение с СУБД? Как вы снизите риск от утечки строки подключения к СУБД? // Это только начало


2) CRUD и прослойка из представлений на уровне СУБД.

Во-первых, ребят, постарайтесь изучить что умеет ваша СУБД. Потому как оказывается, что добрая половина велосипедов — своя авторизация, протоколы, псевдотранзакции, аудит, репликация, репорты, ETL, полнотекстовый поиск по документам — всё это уже есть. И если даже и делать обёртки, то выносить их в отдельное приложение-шлюз смысла я не вижу.

Дальше. Как уже говорил, у вас будет куча приложений, у которых общими будут только обрабатываемые данные, да и то — потребуется разные представления одних и тех же данных. Это всё умеет СУБД. Как реализовать такую прослолйку дело десятое. Я предпочитаю хранимые процедуры по следующим причинам — output parameters, no sql injection и имперсонация. Про последнее: допустим, для создания пользователя СУБД вам нужны права администратора. Вы не даёте их всем пользователям, а создаёте хранимку, прописываете EXECUTE AS (для SQL Server), даёте доступ к этой хранимке какой-то группе пользователей — всё работает. В чём фишка: Даже если утечёт строка подключения, то пользователь не сможет натворить ничего такого, что он не мог бы сделать через клиентское приложение. В результате, вы без боязни можете использовать репорты, EXCEL, что угодно в качестве клиента — перимет безопасности у вас ограничен SQL сервером. Да, имперсонацию можно организовать и ч/з представления, но это сложнее.

Главный недостаток: СУБД у вас перестаёт быть just storage — она становится тру сервером. Если вы на это не готовы — то сорри. Пока хватит

3) EF
А>спасибо всегда интересно услышать мнение разаработчика технологии, а то иногда получается, что они что-то пишут потом кто-то галюцинирует на них, а нам как конечным пользователям приходиться уже галюцинировать на галюцинации (утрирую)

А>иными словами вы говорите что если это не простой пример с MSDN`а а реальное приложение, то нужно очень сильно задуматься я с вами согласен... ктсати, как-то мне рассказали шутку чем отличается архитектор от разработчика: разработчик, начало проекта. разработчик думает: так, и как бы эту хрень вообще сделать? архитектор, начало проекта: мысли архитектора, так, и каким способом попробовать эту хрень сделать в этот раз так что б не скучно было

Повторюсь. Я побоюсь использовать сырую неотстоявшуюся технологию, с которой я ещё не поимел опыта, как core foundation для нового проекта. Тем более для такого масштабного. Как одну из технологий на клиенте, которая не требует изменения архитектуры сервера — почему бы и нет.

Один из раздражающих моментов в EF — стремление по любому поводу пинать сервер. Загрузка согласованного набора данных — щитай вообще недостижимая мечта. Если будет время, потрэйстье SQL запросы, которые сыпятся на сервер, особенно запросы с eager loading.

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

Щастья вам

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

S>2) CRUD и прослойка из представлений на уровне СУБД.

S>Дальше. Как уже говорил, у вас будет куча приложений, у которых общими будут только обрабатываемые данные, да и то — потребуется разные представления одних и тех же данных. Это всё умеет СУБД. Как реализовать такую прослолйку дело десятое. Я предпочитаю хранимые процедуры по следующим причинам — output parameters, no sql injection и имперсонация. Про последнее: допустим, для создания пользователя СУБД вам нужны права администратора. Вы не даёте их всем пользователям, а создаёте хранимку, прописываете EXECUTE AS (для SQL Server), даёте доступ к этой хранимке какой-то группе пользователей — всё работает. В чём фишка: Даже если утечёт строка подключения, то пользователь не сможет натворить ничего такого, что он не мог бы сделать через клиентское приложение. В результате, вы без боязни можете использовать репорты, EXCEL, что угодно в качестве клиента — перимет безопасности у вас ограничен SQL сервером.

Еще раз. Зачем хранимые процедуры для CRUD? Я работал в проекте где для каждой сущности писались 4 CRUD процедуры. На 20 сущностях вносить исправления было очень трудоемкой задачей. Кроме того изменения БД плохо поддаются контролю версий.

Если использовать ХП для выборок, то оптимизировать запросы станет гораздо сложнее. В большенстве случаев для разных сценариев придется писать разные хранимки.

S>Да, имперсонацию можно организовать и ч/з представления, но это сложнее.
Зачем имперсонация для CRUD?

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

S>3) EF
S>Один из раздражающих моментов в EF — стремление по любому поводу пинать сервер. Загрузка согласованного набора данных — щитай вообще недостижимая мечта. Если будет время, потрэйстье SQL запросы, которые сыпятся на сервер, особенно запросы с eager loading.
Я смотрел запросы. Очень прилично получается, особенно если не писать выборки в виде EntitySet.Include("Все") и не загружать каждую ссылку вручную.

S>Как-то больще исповедую пакетную обработку аля пнул сервер — получил согласованный набор данных — отсоединился, поработал — пнул сервер....
Нагрузка очень хорошо сглаживается и распределяется по клиентам.
ADO.NET Data Servces вам в помощь.

S>Щастья вам
И вам.

Ничего, что я сразу на 2 поста тов. gandjustas отвечу?

G>Еще раз. Зачем хранимые процедуры для CRUD? Я работал в проекте где для каждой сущности писались 4 CRUD процедуры. На 20 сущностях вносить исправления было очень трудоемкой задачей. Кроме того изменения БД плохо поддаются контролю версий.

Сразу — говорю исключительно про SQL Server. Опыта длительной эксплуатации других СУБД нет — исключительно "поиграться".

Видно вы меня не так поняли — я не утверждял, что CRUD должно быть и должно быть через хранимые процедуры.
Я писал, что если СУБД для вас не just storage, если одни и те же данные используются несколькими приложениями, то рано или поздно вам придётся заводить отдельные прослойки, представления — что хотите — для каждого приложения. Как это делать уже дело десятое. Я исповедую хранимые процедуры, по целому ряду причин: инкапсуляции SQL кода, лёгкость администрирования, возможность разграничения доступа, возможность сложных алгоритмов и т.п.


Как success story: переход на SQL Server 2008 занял 2 дня с момента получения диска. Причём это не было просто восстановление из бэкапа, добавилось хранение файлов ч/з FILESTREAM (раньше файлы хранились напрямую на жёстком, доступ был ч/з CLR stored procedures), и включен полнотекстовый поиск по этим файлам (раньше коннектились ч/з ODBC к IndexingServices, который индексировал файлы на диске). Изменилось то ли 5, то ли 6 мест на сервере. Клиент ничего не почуствовал.

Про редактирование изменений. Умейте готовить SQL Server Management Studio умеет контроль версий (как минимум TFS и Source Safe, ещё был бодяжный плогин к тортойзу).

Есть бесподобнейшая приблуда к VS Team Suite 2008 (точнее уже часть студии) — VSTS Database Edition. Недавно GDR вышел (что-то типа R2 для виндов). Оно как раз умеет создавать проект из реальной БД/БД по проекту и умеет их синхронизировать. Самое оно для массивного редактирования кода. Плюс все приятные мелочи студии. И начиная с GDR оно вроде бы умеет работать не только с SQL Server, но и с другими СУБД.

Да! можно спросить, вы сразу 20 сущностей редактировали?

G>Если использовать ХП для выборок, то оптимизировать запросы станет гораздо сложнее. В большенстве случаев для разных сценариев придется писать разные хранимки.

Да что вы говорите Ну дык никто не мешает создать view и дать доступ к нему. Как минус — чуть сложнее реализовать нетривиальную фигню типа чтения файлов, приходится отслеживать возможность SQL-инъекций, ну и крайне муторно пытаться оптимизировать узкие места, когда завтра какой-нибудь [censored] поломает твой запрос потому что некрасиво.

G>Зачем имперсонация для CRUD?

Ну сценарий я тебе приводил: приложения имеют доступ только к хранимкам, права, необходимые каждому приложению раздаются ролям, пользователи приложений включаются в эти роли. Прямого доступа к таблицам нет. На этом этапе можно вместо хранимок использовать представления.
Сценарий 2: часть хранимок особо критична (допустим, у них внутри создаётся SQL код и возможна инъекция) — эти хранимки работают с пониженными правами.
Сценарий 3: хранимка работает с удалённым сервером (Linked Server в терминах MS SQL). Она запускается от имени служебного пользователя, имеющего доступ к этому серверу. Больше никак к этому серверу не подрубиться.
На самом деле эта ситуация не так уж и часто встречается, тем не менее ещё +1 в пользу хранимых процедур.

S>>3) EF
S>>Один из раздражающих моментов в EF — стремление по любому поводу пинать сервер. Загрузка согласованного набора данных — щитай вообще недостижимая мечта. Если будет время, потрэйстье SQL запросы, которые сыпятся на сервер, особенно запросы с eager loading.
G>Я смотрел запросы. Очень прилично получается, особенно если не писать выборки в виде EntitySet.Include("Все") и не загружать каждую ссылку вручную.

Да. Согласен. Сценарий: у вас список чего-то, вы по переходу показываете детали. У вас всего 2 варианта: либо дёргаете данные по мере необходимости, либо загружате их скопом заранее. Во втором случае как раз и получается кошмарные запросы с кучей жойнов и вложенных запросов. В первом — вы получаете рассогласованные во времени наборы данных. Как пошлый пример: В мегагитлерредакторе каждая страничка подгружается при прокрутке. В результате первая страница договора отражает ваши изменения, вторая — внесённые главбухом, который ваши изменения не читал, третья удалена ещё кем-то, кто видит первые две страницы ДО изменений. Попа
Кроме того, постоянные запросы при выделении нового элемента в списке очень сильно сношают сеть и сервер. Не все оптимизации полезны

S>>Как-то больще исповедую пакетную обработку аля пнул сервер — получил согласованный набор данных — отсоединился, поработал — пнул сервер....
G>Нагрузка очень хорошо сглаживается и распределяется по клиентам.
G>ADO.NET Data Servces вам в помощь.

Ггг. Вы их щупали/читали/пользовали? Astoria — это эмуляция EAV хранилища через вебсервисы поверх EF поверх SQL Server'a. Всё оптимизируем ?)))

Под нагрузкой имелось в виду другое — вся логика, относящаяся к работе клиента, живёт на клиенте. Он работает с данными, которые нужны пользователю. Эти данные заблаговременно загружены, клиент отсоединён от серера до того момента, пока не требуется сохранить изменения или попросить сделать что-то эзотеричное, допустим тот же полнотекстовый поиск, к серверу не подсоединяется.
Вот такой вот сценарий на EF реализовать тяжелоато будет.

Ещё вопросы ?