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

интересно было бы услышать мнения за и против использования хранимых процедур в 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 реализовать тяжелоато будет.

Ещё вопросы ?

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

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

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

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

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

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

S>Да! можно спросить, вы сразу 20 сущностей редактировали?
Слава богу нет, но когда приходилось рабоать сразу с тремя сущностями уже становилось плохо.

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

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

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

S>Ну сценарий я тебе приводил: приложения имеют доступ только к хранимкам, права, необходимые каждому приложению раздаются ролям, пользователи приложений включаются в эти роли. Прямого доступа к таблицам нет. На этом этапе можно вместо хранимок использовать представления.
Это понятно.

S>Сценарий 2: часть хранимок особо критична (допустим, у них внутри создаётся SQL код и возможна инъекция) — эти хранимки работают с пониженными правами.
Причем здесь CRUD? Диначмическая генерация SQL для CRUD — это сильно.

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


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

S>Да. Согласен. Сценарий: у вас список чего-то, вы по переходу показываете детали. У вас всего 2 варианта: либо дёргаете данные по мере необходимости, либо загружате их скопом заранее. Во втором случае как раз и получается кошмарные запросы с кучей жойнов и вложенных запросов. В первом — вы получаете рассогласованные во времени наборы данных.
А вы план запросов видели? Зачастую они получаются эффективнее, чем написанные вручную.
Если вам нужен согласованный набор — грузите все сразу.

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

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

S>Ггг. Вы их щупали/читали/пользовали? Astoria — это эмуляция EAV хранилища через вебсервисы поверх EF поверх SQL Server'a. Всё оптимизируем ?)))
Пробовал, использовал. Хорошо работает, небольшой геморрой доставляет изменение связей. Едиственный недостаток — невозможно описать проекцию, надо тянуть полные сущности. Хотя наверное можно изватиться через батчи, но не хочется.

S>Под нагрузкой имелось в виду другое — вся логика, относящаяся к работе клиента, живёт на клиенте. Он работает с данными, которые нужны пользователю. Эти данные заблаговременно загружены, клиент отсоединён от серера до того момента, пока не требуется сохранить изменения или попросить сделать что-то эзотеричное, допустим тот же полнотекстовый поиск, к серверу не подсоединяется.
S>Вот такой вот сценарий на EF реализовать тяжелоато будет.
Снова ADO.NET DataServices и все оказывается легко.
Если нужно действительно occasionally connected apllication, то смотри в сторону Sync Services.

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

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

Эммм. И о чём мы спорим?

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

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

Этто да ИМХО, за СУБД должен отвечать очень узкий круг товарищей, очень хорошо знающий, что они ломают. Ибо чревато.

G>Слава богу нет, но когда приходилось рабоать сразу с тремя сущностями уже становилось плохо.
Иногда спасает возможность VSTS DB edition рефакторить код и показывать зависимости. Иногда нет

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

G>Во-первых SQL-иньекции надо отслеживать на уровне приложения, а не на уровне базы.
Если доступ только через хранимые процедуры — то нет //сорри, уже стебаюсь

G>Во-вторых офигенный способ оптимизации "тяжелых" запросов — создание индексированных вьюх по ним, если возможно.
Угу. А можно создать вьюху и процедуру поверх неё //сорри, ещё раз стебаюсь

G>>>Если использовать ХП для выборок, то оптимизировать запросы станет гораздо сложнее. В большенстве случаев для разных сценариев придется писать разные хранимки.
[skipped]
G>В-третьих, если у вас в процедуре выборка, а для программы нужно подмножество записей, возвращенных процедурой (выполняется select .. where запрос), то серверу придется подять все страницы данных для записей, возвращаемых процедурой, несмотря на то что часть окажется ненужной. Аналогично с проекцией.
Угу. Ещё раз. Если у нас известна структура данных — то ХП. Нет — вьюхи. Я ж не против.

S>>Сценарий 2: часть хранимок особо критична (допустим, у них внутри создаётся SQL код и возможна инъекция) — эти хранимки работают с пониженными правами.
G>Причем здесь CRUD? Диначмическая генерация SQL для CRUD — это сильно.
На самом деле эзотерика. Единственный вариант был — обращение к чужому серваку по запросу снаружи. Структуру сервака наружу светить низзя, запросы нужны сложные, данных много. Вот и игрались...

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

Так и делалось. Там было слегка шизофреничное требование чтоп никто кроме sa не мог написать код, который дёргает linked server. Если честно не помню, но реально там БЫЛО НАДО. Хотя тоже изотерика.


S>>>>3) EF
G>А вы план запросов видели? Зачастую они получаются эффективнее, чем написанные вручную.
Для единичной подгрузки — да.
G>Если вам нужен согласованный набор — грузите все сразу.
Создаётся либо 1 жуткий запрос с денормализацией, либо n+1 запросов по числу главных записей. Пару раз получалось 2 запроса — 1 для мастера, 1 для details, но так и не смог понять по какому принципу, ибо меня нашёл дедлайн.

S>>Как пошлый пример: В мегагитлерредакторе каждая страничка подгружается при прокрутке. В результате первая страница договора отражает ваши изменения, вторая — внесённые главбухом, который ваши изменения не читал, третья удалена ещё кем-то, кто видит первые две страницы ДО изменений. Попа
G>Это всегда попа независимо от технологии доступа к данным.
Да, но тут неинтуитивная попа какая-то. Пользватель не просил "обновись", а оно, ссука...

G>>>ADO.NET Data Servces вам в помощь.
S>>Ггг. Вы их щупали/читали/пользовали? Astoria — это эмуляция EAV хранилища через вебсервисы поверх EF поверх SQL Server'a. Всё оптимизируем ?)))
//Извиняюсь за неоправданный сарказм. Возможно не так вас понял.
G>Пробовал, использовал. Хорошо работает, небольшой геморрой доставляет изменение связей. Едиственный недостаток — невозможно описать проекцию, надо тянуть полные сущности. Хотя наверное можно изватиться через батчи, но не хочется.

ИМХО, накладные расходы всё-таки великоваты Если честно, так и не понял в чём цимус, если не нужны EAV и веб-сервисы.

G>Если нужно действительно occasionally connected apllication, то смотри в сторону Sync Services.
Да нет, тру OCA не требуется, так просто львиную долю задач удаётся организовать по принципу "открыл/сохранил". Удобно.

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

G>>В-третьих, если у вас в процедуре выборка, а для программы нужно подмножество записей, возвращенных процедурой (выполняется select .. where запрос), то серверу придется подять все страницы данных для записей, возвращаемых процедурой, несмотря на то что часть окажется ненужной. Аналогично с проекцией.
S>Угу. Ещё раз. Если у нас известна структура данных — то ХП. Нет — вьюхи. Я ж не против.
Даже если известна выборка (фильтр и проекция), минимально необходимая для каждой задачи, то для каждой такой выборки надо писать ХП. В итоге количество хранимок оказывается гораздо больше чем 4*кол-во таблиц.

S>>>>>3) EF
G>>А вы план запросов видели? Зачастую они получаются эффективнее, чем написанные вручную.
S>Для единичной подгрузки — да.
И не для единичной тоже.

G>>Если вам нужен согласованный набор — грузите все сразу.
S>Создаётся либо 1 жуткий запрос с денормализацией, либо n+1 запросов по числу главных записей. Пару раз получалось 2 запроса — 1 для мастера, 1 для details, но так и не смог понять по какому принципу, ибо меня нашёл дедлайн.
Время выполнения и план запроса оценивать надо, а не внешний вид выборок.

G>>>>ADO.NET Data Servces вам в помощь.
S>>>Ггг. Вы их щупали/читали/пользовали? Astoria — это эмуляция EAV хранилища через вебсервисы поверх EF поверх SQL Server'a. Всё оптимизируем ?)))
S>//Извиняюсь за неоправданный сарказм. Возможно не так вас понял.
G>>Пробовал, использовал. Хорошо работает, небольшой геморрой доставляет изменение связей. Едиственный недостаток — невозможно описать проекцию, надо тянуть полные сущности. Хотя наверное можно изватиться через батчи, но не хочется.

S>ИМХО, накладные расходы всё-таки великоваты Если честно, так и не понял в чём цимус, если не нужны EAV и веб-сервисы.
Какие накладные расходы? Как вы решаетет эту задачу другими средствами?

G>>Если нужно действительно occasionally connected apllication, то смотри в сторону Sync Services.
S>Да нет, тру OCA не требуется, так просто львиную долю задач удаётся организовать по принципу "открыл/сохранил". Удобно.

Здравствуйте, Sinix.
хорошо, что решили ответить и задаете вопросы — так будет легче проверить задуманое на "устойчивость". отвечать буду по мере постановки вопросов, а на дальнейшее спрашивайте критикуйте и главное предлагайте альтернативы — это мне полезно... и так :

S>Тааак, чтой-то тут много написали
да получилось много тектса, но сложность задачи определяется сложностью пердметной области, говривал дядька буч

S>Вы знаете, из моего опыта — это будет ОЧЕНЬ большой проект.

очень не очень — но большой, после того как я работал в компании где проекты длились 6-12 месяцев я пришел в компанию где большим проектом считался проект 3-4 месяца. но вообще, по моим меркам, проект будет боьшим.

Я ни разу не сталкивался с тем, чтобы в конкретном приложении — не во всей системе, а в конкретном приложении — использовалось больше пары десятков независимых сущностей, даже десяток — уже много.
охотно соглашусь — для этого есть декомпозиция и используя ее разбиваем большие херни на маленькие имеено в этом и первое что мне не нравиться в EF — невозможность декомпозии модели... EF работает по принципу или все или ничего — а такой механизм как декомпозиция с их точки зрения или не существует или зло т.е. они предоставляют возможность работать или просто одной "большой" моделью (если будите настаивать дам линки на майкрософовский блог), или с нескольки абсолютно независимыми между собой моделями, но так чтобы одна и та же сущность могла разделяться несколькими моделями без последующей правки сгенерированного кода или без специальной ручной правки xml`я мапинга для разделения модели (тоже где-то находил линк умельца котрый с этим столкнулся и решение от производителей его не совсем устроило EF этого не позволяет, и это грусно


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

и не хочу ее туда пихать я где-то уже на этот форуме писмал о невозможности декомпозиции модели в EF.

S>ИМХО, у вас в конце-концов получится несколько десятков моделей EF, которые будут частично перекрываться. И вот тут вам грядёт попа. Потому как
S>а) в разных моделях вам понадобится разный набор атрибутов для одной и той же сущности
для моего понимания того что вы сказали: вы имеете в виду что будут модели котрые будут разделять между собой некторые сущности — абсолютно. и общий набор атрибутов характеризующий разделяемую сущность будет разбросан между несколькими (как правило 2, максимум 3) моделями? — это правда. при наличии техник, позволяющих с этим бороться (придется вмешиваться в генеренный код или мапинг как я сказал ранее — не очень нравиться но работает) это помжно назвать не жопой, а скорее неудобством.
S>б) БЛ в этих моделях будет очень слабо пересекаться.
искренне надеюсьчто пересекаться вообще не будет. а разделяемые сущности хотя и будут присутсвовать на нескольких моделях, но все же в результате это будет одна сущность, так как определяеться она как партиал и соответственно логика работы с ней будет одинакова... или я не понял ...

S>в) эти два представления должны быть соответствовать одним и тем же данным.
ну да это я ответил в б)
S>г) Сам доступ к этим данным желательно проводить ч/з обёртки-представления (аудит, контроль доступа и т.п.)
как по мне в идеале было бы хорошо везде сипользовать именно эти сущности полученные в результате генерации EF и при помощи атрибутов указывать и права доступа и чкто как сериализоваться должно и т.д. по моему это было бы "желательно", но поскольку это не совсем так, то да иногда приходиться писать овертки — например для того чтобы передать сущности на уровень представления для SL.

S>Решать такие пролемы в терминах объектной модели — ещё большая попа. Если интересует — отпишусь подробней, пока оставим. весьма интересует, хотя бы потому что я не понял почему жопа решать проблемы в оьектной модели (всмысле не вообще а в контексте нашего разговора). было бы весьма полезно узнать о том кто на какаие граблли наступал чтобы самому их обойти — так что очень даже интреесно... только здесь нужно четко сформулировать проблему о которой вы говорите...

S>Из последней цитаты следует наличие аппсервера. Поправьте если не прав.
я не совсем знаком с шаблоном Application Server — бля меня это скорее не шаблон а реальный сервер где выполняются Java приложения, по этому я попытаюсь ответить в терминах определение которых можно найти например у мартина фалера. так вот у меня есть слой служб (ServiceLayer), в них выполняется логика домена, доступ к ServiceLayer удаленным клиентам предоставляется через RemoteFasade. RemoteFasade использует DTO для переноса данных между слоями и в моем случае между уровнями.

S>Воот. Видите, проекту ещё жить и жить. А вы уже ограничиваете клиентов одной платформой,
относительно платформы — рассматривалась возможность доступа к сервисам со стороны Java -но разработка на нескольких платформах не планируетс я- да и зачем? одна платформа — одни проблемы — две платформы — две проблемы на самом деле не вижу смысла учатсия нескольких платформ — проблемы разработки — нужен персонал котрый бы разирался и в Java и .Net а таких днем с огнем, проблема интеграции, сопровождения, а какой смысл — котороче я не вижу для себе бенефитов от испоьзования нескольких платформ по этому сознательно ограничиваю разработку одной — нетом. а при необхоимлости взаимодействия WS нам поможет

да ещё и одним фреймворком. Не, сначала это некритично, но вот потом, когда EF объявят слегка устаревшим (как недавно Linq for SQL)... Здесь я конечно передёргиваю — такая радость наступит очень и очень нескоро — очень уж много на EF поставлено.
обявление ODBC устаревшой технологией не означает что приложения с ее использованием необходимо переписывать — драйвера ODBC до сих используются... так что если появиться следующее развитие EF это не будет сигналом для того чтобы переписывать ее, а на собственном опыте вижу что технологии как правило нарастают как мышцы на скелете по этому мне до сих пор никто не мешает пользоваться ADO в случае необхоимости

Но посмотрите, сколько программ умеют ODBC/OLEDB, и сколько — EF. ну это и понятно — сколько ODBC и сколько EF.
Допустим, когда вам потребуются отчёты, вы с удивлением увидите, что МС умеет свой репортсервер или датасеты, кристал репортс умеет свой формат и слегка произвольные объекты, у остальных вендоров — не лучше.
отчеты думаю делать при помощи Reporting Services, но окончательного решения пока нет... если есть рекомендации и т.д. буду плагодарен.

Эксель, допустим — вообще только OLEDB|ODBC // не пробовали аналитику в экселе 2007? очень советую — весчь, если готовить. Если у вас половина систем (не забываем про интеграцию) будет лезть напрямую к СУБД — что вам дают ваши сервисы? ну как я сказал лазить напрямую это грех хотя для аналитики думаю позволительно, так как она не делает изменений, а при наличии необходимости может давать возможность делать аналитику более гибкой и т.д. так что для аналитики прямой доступ наверное возможен.


S>Про одноразовость проекта. Скажите, индивидуальный дух компании так влияет на подсистемы контроля доступа, развёртывания, администрирования? Все эти велосипеды тоже заново пишутся?
не совсем понял: — если Вы о том что я собираюсь писать свой велосипед — то это совершенно не так — подход абсолютно противополжный — я где-то об этом уже писал — чем меньше мы пишем и больше используем библиотек тем лучше — не буду распыляться на эту тему. а относительно контроль доступа — CardSpace, тоносительно развертывания — обыная инсталяция — но не факт что "продукт" вообще будет иметь инсталяшку как таковую — в это не коробочная версия, хотя сделать инсталяшку обычными средствами не преставляется сложности...ну да ладно не тема...относительно администрирования — хотел бы сказать что администрирование будет сделано на основе WMI и с MMC консолью т.д. но... а нафиг ? никому это не нужно а на написание толко приблуды для управления с консоли нужно тратить время ресурсы — а потребности в этом никакой — легче написать кастом средство по управлению правами пользователй, моделью згрузки и т.д. а перформенс каунтеры администратор сможет посмотреть со своей консоли... так что про удобство админов я честно говоря заморачиваюсь мало лишь бы можно было определить что сервисы доступны и работают, и нагрузку системы.

S>Дальше. Сервисы. Что собираетесь использовать? Веб-сервисы в чистом виде или WCF?
в прототипе написаны WCF сервисы которые котрые хостятся на WS.
В любом случае вам потребуется загружать в сервис данные с сервера, применять изменения, переданные клиентом, и отсылать даные обратно. Самостоятельно отслеживать изменения при сериализации EF не умеет.
это правда и весьма грустно. EF позволяет делать изменения простых типов, т.е. не навигационных полей, но вот если менять ссылки... по этому в качестве решения выбран подход когда наружные сервисы имеют интерфейс для изменения данных: например, назначить тоту-то в качестве ссылки вот это ... и передаем в качестве прарамтров обе сущности ... можно делать изменения в сущностях передавать их сервисам а там парсить — но тогда гимор становиться несоизмериьмо больше — хотя в инете находил примеры таких решений там использоввался рефекшен... но честно — зачем использовать EF вообще если придется так изголяться для апдейта... сейчас рассматриваю еще одну альтернативу DataServices — в некоторых случаях по моему может быть отличным решением... но пока мало повозился.

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

S>Безопасность. Как у вас будет проходить авторизация?
сейчас аторизация на ASp.Net, но сейчас исследую CardSpace. и скорее всего будет следующий сценарий:
клиент регистрируется, получает сертификат, при логине UI позволяет выбраеть сертификат, пользователь выбирает сертификат и отсылает его, система получает сертификат проверяет и таким образом аутентифицирует пользователя и назначает ему роль в системе. а дальше все права пляшут от роли.
пока это работает для пользователя, но пока работа сервтификатов не прикручена для WCF сервисов — дело времени. я кстати, пока не знаю как правильно организовать рботу сервисов(они без состояния -это обязательно) с тем чтобы не аутентифицировтаь пользователя каждый раз при вызове метода сервиса... а однажды аутентифицировавшись использовать какой-то токен в последующих вызовах, так что если будут подсказки — буду рад помощи...

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

Как вы снизите риск от утечки строки подключения к СУБД? // Это только начало
подключение к базе осуществляться сервисом под системной учетной записью NetworkService, а DB инстанс и база — это единственное, что остается в строке подключения — шифруется стандартным механизмом шифровки web.config файла. получить web.config от iis будет тяжеловато, но если преположить что файл был получен другим путем, то строка подключения защищается настройкой конфигурационного провайдера: RSAProtectedConfigurationProvider or DPAPIProtectedConfigurationProvider и шифруется утилитой aspnet_regiis.
если что не так — советы, рекомендации ...


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

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

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

В результате, вы без боязни можете использовать репорты, EXCEL, что угодно в качестве клиента — перимет безопасности у вас ограничен SQL сервером. Да, имперсонацию можно организовать и ч/з представления, но это сложнее. не буду утверждать но по моему excel может использовать WS в качестве источников данных — лично не пользоватлся утверждать не буду — но если это так то это решает проблему.

S>Главный недостаток: СУБД у вас перестаёт быть just storage — она становится тру сервером. Если вы на это не готовы — то сорри. Пока хватит
это меньше всего чего бы я хотел — очень хочется использовать базу как ханилище и только... а все остальное пусть будет самостоятельным — т.е. бизнес логика отдельно, отчетность отдельно и т.д. а все пихать в сервер мне не нравиться ... при наличии отдельных сервисов я могу поставить дополнительную коробку и на какое-то время забыть о производительности а в случае если все в одном то можно забыть про масштабирование вширь, а масштабирование вглубь ограничено... практика гугла показывает что подход с отдельной дополниетельной коробкой более правильный ... гавное чтобы сервисы были без состояний... работая с железаяным кластером я вынес для себя однин подход: сервисы без состояний и сетевая балансировка — это решение имеет не плохой запас прочности.

S>Повторюсь. Я побоюсь использовать сырую неотстоявшуюся технологию
согласен — а когда она остоится ? это слодный вопрос, в моей практике было такое:нет только вышел — я пока его крутил для себя, на одном из совещаний "что делать и как быть" я предложил написать компонент с использованием COM и один старый дяденька скала: — а вы не боитесь все же технология новая... в результате было таки написано приложение с COM/DCOM но все же ... что такое устоявлеестя ил и нет... в другом телекоме я от админа услышал следующее утверждение: мы не пререходим на новую OS пока к ней не выйдет 4SP, я давно уже не работаю в том телекоме, и незнаю перешли они на XP или нет — но 4SP к нему так и нет .... я для себя это воспринимаю как нежелание обучаться новому ... с одной стороны правильно не переходить же каждый день на новую винду если мелкомягкие ее будут выпускать всему должно быть целесообразно
, с которой я ещё не поимел опыта,
любая даже самая длинная дорого начинается с первого шага... вы не имели опыта и я не имел вот мои первые шаги в этом направлении... по роду своей деятельности я консультант — и обязан знать и уметь пользоваться новыми технологиями ... особенно знать что они могут и могут ли вообще помочь сократить стоимость разраотки ... вот тринеруюсь на кроликах
как core foundation для нового проекта. Тем более для такого масштабного.
практически все проекты в которых я участвовал или очень масштабны или не мальенькие — мне так интересней... так что по большому счету выбирать не приходиться... а учиться когда-то нужно... технологические риски в этом проекте учтены — в смысле заложены.
Как одну из технологий на клиенте, которая не требует изменения архитектуры сервера — почему бы и нет.

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

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

S>Щастья вам
спасибо за проявленный интерес и советы. если что буду рад и ругим. а Вам так же удачи

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

S>Ещё вопросы ?

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

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

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

S>>Ну сценарий я тебе приводил: приложения имеют доступ только к хранимкам, права, необходимые каждому приложению раздаются ролям, пользователи приложений включаются в эти роли. Прямого доступа к таблицам нет. На этом этапе можно вместо хранимок использовать представления.
G>Это понятно.
согласен — это довод.


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

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


G>>Во-первых SQL-иньекции надо отслеживать на уровне приложения, а не на уровне базы.
S>Если доступ только через хранимые процедуры — то нет //сорри, уже стебаюсь
поясните мне деревянному о каком инжекшине идет речь? пользоатель на сторое клиента вызывает процедуру, в процедуру передает сущности над которыми нужно выполнить действия. сервис получает сушности и выполняет заложенный алгоритм, алгоритм работает с EF API, в результате на основе этого EF генерирует SQL — все это уже на стороне сервера и врамках кода. в результате где место инжекшина ? потом результат в виде DTO передается на клиента... как пользователь может внедрить свой SQL код ? или я не понимаю о чем речь ?



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

Ёк, шо ж так много-то??? Давайте по порядку.

2 gandjustas:
Мы точно на одном и том же языке разговариваем? Давайте закончим, а то у нас холивар какой-то получается Я в принципе сказал всё что хотел в предыдущих постах и не хочу повторяться. Если коротко:
1) Обёртка к СУБД должан быть, если вы не используете СУБД исключительно для хранения сериализованных объектов.
2) Как делать эту обёртку ваш выбор. Я стараюсь разруливать эти вопросы непосредственно на уровне СУБД, преимущественно посредством хранимых процедур. Я не утверждаю, что это единственно верный путь, но для меня он обладает кучей преимуществ.
3) Я не думаю, что стоит использовать EF кроме как в качестве ещё одного способа поработать с данными. Почему — уже сказано.
4) Это относится и к ADO.NET DataServices и к SyncServices.
Про последние можно похоливарить ещё, но даже сама МС позиционирует асторию как легковесную обёртку для веб-приложений, в которых не требуется хранения защищённых данных. Я не вижу смысла использовать её как-либо еще.

2 Аноним
Вы же сами говорите, что должна быть декомпозиция на отдельные модели, но EF её умеет. Что нужны сервисы, но EF их не умеет. Что ж за преимущества такие у EF, кто ёжики упорно продолжают жрать кактус?)))

Скажите, а почему нельзя использовать старые добрые датасеты? Они и сериализуются, и в хмл-е передаются, и изменения держат, и типизация есть, и LINQ, и sync services их умеют (это к вопросу об Occansionally Connected Applications), и всякие биндинги работают (есть баг с биндингом в WPF, уже год прошу починить). Чаго не хватаит-та? Да, ReportViewer их тоже могёт. Единственное, куда они не совсем подходят — для stateless веб-страничек, но там, имхо, уже проще LINQ for SQL использовать — инициализация контекстов EF ещё дороже датасетов выйдет.

У вас получается, что выставляться наружу будет СУБД (хотя бы для отчётов и интегрируемых систем) и сервисы (для удалённых клиентов). Может, будут сайты и дестктопные приложения? Во всём этом зоопарке нельзя будет сделать общую систему авторизации ч/з CardSpace. И даже если она будет, то общего контроля за разрешения не будет всё равно.
Это азы корректного проектирования — если Пете, Васе и Маше что-то разрешено, то что бы они ни делали, больших прав они не должны получать.
Единственное место, где вы сможете хоть как-то защитить сами данные в этом сценарии — СУБД. Потому как во всех остальных случаях при разграничении доступа вы можете только надеяться, что все приложения-клиенты добровольно реализуют ваши требования и не будут светить то, что не положено.

Если подходить с позиций параноика, то у вас будет дыра в защите: дыра в хосте сервисов — запуск на нём произвольного кода от имени network service — прямой доступ к СУБД. Про доступ от администраторов домена к серверу вообще молчу. Из-за этого одно время на полном серьёзе не хотели включать сервера в домен. Паранойа!

Ну и не используйте без защиты на уровне СУБД windows authentification или прямую sql авторизацию для пользователей. Им ничего не помешает подконнектиться напрямую и нагадить.

Как офтоп. Был реальный случай со сторонним приложением. Строка подсоединения хранилась в отчёте (хардкод программистов) и в датасете (записана визардом). Были права на чтение ко всем табличкам (типа защитили) Информацию аккуратно слили. Хорошо, что я к той софтине не имел никакого отношения

В принципе, своё имхо уже высказал, по веб-сервисам и wcf н ничего не могу подсказать, уж извините. Радует, что проблемы осознаны и приняты во внимание. Дерзайте

2 Monkey-Bee:
Уже отвечал — импресонация использовалась всего пару раз и глубоко унутри СУБД. Там была хранимка, которая дёргала другую, которая обращалась к удалённому источнику. Задача была запустить вторую хранимку с правами другого пользователя, не поломав owner chain. Всё. Что вам так не понравилась эта имперсонация-то?

Про EAV-в ответе gandjustas.

// извините, что давлю опытом
Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.

После этого предложения типа "написать сервисы и пускай пользователи сами берут что им надо"... неа

Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.

Я уже подустал вдалбливать элементарщину — чем проще система и чем меньше у неё периметр безопасности — тем она защищённей. В варианте с сервисами вы должны защищать сервер СУБД, канал до хоста сервисов (по сути всю локальную сеть) и сам хост. Вы должны отслеживать бизнес-логику на сервисе и убеждаться что она не открывает непредвиденный доступ к исходным данным. При этом товарищи, ответственные за сервисы будут орать "Уйди, ссуко! Так надо!", ибо так действительно надо и они вовек не поймут какого от них требуют безопасного кода, который мешает медитировать на священные потребности бизнеса, отныне и вовеки — трындец!

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

S>Скажите, а почему нельзя использовать старые добрые датасеты? Они и сериализуются, и в хмл-е передаются, и изменения держат, и типизация есть, и LINQ, и sync services их умеют (это к вопросу об Occansionally Connected Applications), и всякие биндинги работают (есть баг с биндингом в WPF, уже год прошу починить). Чаго не хватаит-та?
Кто-то говорил про накладные расходы Data Services?

S>Как офтоп. Был реальный случай со сторонним приложением. Строка подсоединения хранилась в отчёте (хардкод программистов) и в датасете (записана визардом). Были права на чтение ко всем табличкам (типа защитили) Информацию аккуратно слили. Хорошо, что я к той софтине не имел никакого отношения
Доступ к базе был из внешней сети?

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

S>После этого предложения типа "написать сервисы и пускай пользователи сами берут что им надо"... неа
Как раз сервисы с политиками безопасноти внутри них в данном случае — очень хорошее врешение, а наваливать на БД эти задачи — перебор.

Вы конечно можете использовать MS SQL Server как сервер приложений, вам придется писать много кода на TSQL, что заметно удорожает поддержку и лишает вас возможности распределения нагрузки.

S>Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.

S>Я уже подустал вдалбливать элементарщину — чем проще система и чем меньше у неё периметр безопасности — тем она защищённей. В варианте с сервисами вы должны защищать сервер СУБД, канал до хоста сервисов (по сути всю локальную сеть) и сам хост.
Это решается очень просто.

S>Вы должны отслеживать бизнес-логику на сервисе и убеждаться что она не открывает непредвиденный доступ к исходным данным.
Это проверить граздо проще, чем в SQL.

S>При этом товарищи, ответственные за сервисы будут орать "Уйди, ссуко! Так надо!", ибо так действительно надо и они вовек не поймут какого от них требуют безопасного кода, который мешает медитировать на священные потребности бизнеса, отныне и вовеки — трындец!
Вы действительно работаете с такими людьми? Я в основном встречал адеквактных разработчиков, которые понимали в безопасности и знали зачем она нужна.


Вообще не стоит свой негативный опыт выставлять как архитектурные проблемы.

S>>Скажите, а почему нельзя использовать старые добрые датасеты? Они и сериализуются, и в хмл-е передаются, и изменения держат, и типизация есть, и LINQ, и sync services их умеют (это к вопросу об Occansionally Connected Applications), и всякие биндинги работают (есть баг с биндингом в WPF, уже год прошу починить). Чаго не хватаит-та?
G>Кто-то говорил про накладные расходы Data Services?

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

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

S>>Как офтоп. Был реальный случай со сторонним приложением. Строка подсоединения хранилась в отчёте (хардкод программистов) и в датасете (записана визардом). Были права на чтение ко всем табличкам (типа защитили) Информацию аккуратно слили. Хорошо, что я к той софтине не имел никакого отношения
G>Доступ к базе был из внешней сети?
Доступ к базе был из локальной сети. Хватило

S>>Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
S>>Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.
G>Такое как раз решается на уровне сервера приложений, а доступ к БД открывается только серверу.

Ребят, это, ёпть, сферический конь в вакууме. У вас сервер приложений умеет всё, что умеет СУБД? И даже тру транзакции? И даже объясняет другим системам, что он это может? И вы интегрировались с этими системами? И делали нечто похожее на тру синхронную репликацию и массивную передачу данных? И всё это работало через вебсервисы? Как я вам завидую...

S>>После этого предложения типа "написать сервисы и пускай пользователи сами берут что им надо"... неа
G>Как раз сервисы с политиками безопасноти внутри них в данном случае — очень хорошее врешение, а наваливать на БД эти задачи — перебор.

Хорошо. Простенький сценарий: Все пользователи в группе A и во всех группах, вложенных в группу A имеют право обновлять часть полей сущности B, находящейся в одной из подкатегорий категории C, но только если это обновление удовлетворяет нескольким сиюминутным требованиям, затрагивающим чуть ли не половину всех данных. Для простоты допустим, что пользователь должен иметь право на чтение сущности B2 (права раздаются аналогично — через группы и категории).

Это правило является абсолютным и должно выполняться без исключенй вне зависимости от того, каким способом был получен доступ к системе (репорты, веб-клиент или офис — неважно).

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

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

Если вы используете первый подход, то сгенеренные запросы можно завернуть в представления/хранимки на субд. Во вторм подходе вам придётся выгребать 5-6 разнородных структур данных, которые к тому же могут менять свою структуру от версии к версии и искать их пересечение на промежуточном уровне. Падение производительности сами можете представить.

G>Вы конечно можете использовать MS SQL Server как сервер приложений, вам придется писать много кода на TSQL, что заметно удорожает поддержку и лишает вас возможности распределения нагрузки.

Вам по-любому придётся писать часть кода на t-sql, прямо или косвенно. Если этот код будет скрыт в набор хранимых процедур или представлений, у вас будут хотя бы понимание основ того, как работает ваша система и что можно соптимайзить/что нельзя, где закрыть дыры, где не закрывать и т.п. Про нагрузку, имхо — самый большой миф. Затраты на массовую обработку однотипных запросов обычно куда меньше, чем затраты на передачу, преобразование больших объёмов данных и распределённые блокировки.

S>>Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.

S>>Я уже подустал вдалбливать элементарщину — чем проще система и чем меньше у неё периметр безопасности — тем она защищённей. В варианте с сервисами вы должны защищать сервер СУБД, канал до хоста сервисов (по сути всю локальную сеть) и сам хост.
G>Это решается очень просто.

Предложите ваш проект для интрасети. Напомню, в исходной постановке вопроса всё равно требуется прямой доступ к СУБД.

S>>Вы должны отслеживать бизнес-логику на сервисе и убеждаться что она не открывает непредвиденный доступ к исходным данным.
G>Это проверить граздо проще, чем в SQL.
Тааа? Когда у вас мегалогика бизнесс-процесса на полкило текста? Вы доверяете всей БЛ или у вас некие общие методы типа "проверь, могу ли я изменить себя", которые надо не забывать дёргать? Лукавите, ИМХО

S>>При этом товарищи, ответственные за сервисы будут орать "Уйди, ссуко! Так надо!", ибо так действительно надо и они вовек не поймут какого от них требуют безопасного кода, который мешает медитировать на священные потребности бизнеса, отныне и вовеки — трындец!
G>Вы действительно работаете с такими людьми? Я в основном встречал адеквактных разработчиков, которые понимали в безопасности и знали зачем она нужна.

О тааа, что такое безопасность своих данных они понимали. Что если я им дам права на запись, их код сможет поломать чужую работу... не объяснить никогда


G>Вообще не стоит свой негативный опыт выставлять как архитектурные проблемы.
Не надо. Этто очень позитивный опыт Очень быстро учишься видеть проблемы до того, как они придут. Или не учишься.

Плиз, читайте внимательнее. Я по сути пишу третий раз одно и то же. Давайте действительно закончим.

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

S>>>Скажите, а почему нельзя использовать старые добрые датасеты? Они и сериализуются, и в хмл-е передаются, и изменения держат, и типизация есть, и LINQ, и sync services их умеют (это к вопросу об Occansionally Connected Applications), и всякие биндинги работают (есть баг с биндингом в WPF, уже год прошу починить). Чаго не хватаит-та?
G>>Кто-то говорил про накладные расходы Data Services?

S>Ну здесь накладные расходы будут как минимум сопоставимы. Ну и писалось уже, что датасеты хороши когда надо кэшить данные. Скажите честно, вы читаете только первые предложения из каждого абзаца?
Я все читаю, но датасеты всегда полностью передаются по сети (вместе со схемой и пр.). В Data Services вы передаете и получаете только необходимое. Причем схема данных не передается.

S>Мы по ходу говорим реально про разные вещи. Вы — про систему, где реально оторвать приложения от СУБД и заставить их пользоваться _только_ вебсервисами и только через авторизацию. Причём пишет сервисы только ограниченный круг высококвалифицированнных разработчиков.
S>Я — про реалворлд систему, когда у нас есть жуткая среда, где пользователи — все от локальных секретарш и пользователей сайта до недоадминистраторов и сторонних разработчиков. И все хотят странного
По вашему в реалворд системах каждый кто захочет лезет в базу? Это скорее исключение.
Опять-таки ваш опыт в данном случае очень субъективнен.

S>>>Как офтоп. Был реальный случай со сторонним приложением. Строка подсоединения хранилась в отчёте (хардкод программистов) и в датасете (записана визардом). Были права на чтение ко всем табличкам (типа защитили) Информацию аккуратно слили. Хорошо, что я к той софтине не имел никакого отношения
G>>Доступ к базе был из внешней сети?
S>Доступ к базе был из локальной сети. Хватило
Даже в локальной сети можно ограничить доступ в базу.
Это должно быть проблемой админа, а не программистов.

S>>>Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
S>>>Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.
G>>Такое как раз решается на уровне сервера приложений, а доступ к БД открывается только серверу.

S>Ребят, это, ёпть, сферический конь в вакууме. У вас сервер приложений умеет всё, что умеет СУБД?
Нет, а зачем? Он умеет столько сколько достаточно для решения бизнес задач.

S>И даже тру транзакции?
Что такое тру транзакции? Если надо обрабатывать длительную бизнес-транзакцию, то это делается средствами, отличными от транзакций БД.

S>И даже объясняет другим системам, что он это может?
Да, веб-сервисы такое умеют

S>И вы интегрировались с этими системами?
Да

S>И делали нечто похожее на тру синхронную репликацию и массивную передачу данных?
Что значит "нечто похожее на тру синхронную репликацию" ?
Массивную передачу данных делали, открывать доступ к базе кому-попало не приходилось.

S>И всё это работало через вебсервисы? Как я вам завидую...
И отлично работало

S>>>После этого предложения типа "написать сервисы и пускай пользователи сами берут что им надо"... неа
G>>Как раз сервисы с политиками безопасноти внутри них в данном случае — очень хорошее врешение, а наваливать на БД эти задачи — перебор.

S>Хорошо. Простенький сценарий: Все пользователи в группе A и во всех группах, вложенных в группу A имеют право обновлять часть полей сущности B, находящейся в одной из подкатегорий категории C, но только если это обновление удовлетворяет нескольким сиюминутным требованиям, затрагивающим чуть ли не половину всех данных. Для простоты допустим, что пользователь должен иметь право на чтение сущности B2 (права раздаются аналогично — через группы и категории).
S>Это правило является абсолютным и должно выполняться без исключенй вне зависимости от того, каким способом был получен доступ к системе (репорты, веб-клиент или офис — неважно).
S>При этом пользователь очень активно работает с сущностями, на которые накладываются ограничения.
S>По сути тут всего два метода реализации — либо генерить сложные запросы, которые будут отличаться всего-то айдишником изменяемой сущности, либо выгребать тонны данных на промежуточный слой и разруливать алгоритм уже там.
S>Если вы используете первый подход, то сгенеренные запросы можно завернуть в представления/хранимки на субд. Во вторм подходе вам придётся выгребать 5-6 разнородных структур данных, которые к тому же могут менять свою структуру от версии к версии и искать их пересечение на промежуточном уровне. Падение производительности сами можете представить.
Задачами авторизации пусть занимается сервис, а проверки бизнес-правил можно искапсулировать в хранимаках или триггерах. Повышение произодительности можете себе представить.
Хотя я обычно раздаю права не на основе сущностей, а на основе действий, выполняемых в системе.


S>>>Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.

S>>>Я уже подустал вдалбливать элементарщину — чем проще система и чем меньше у неё периметр безопасности — тем она защищённей. В варианте с сервисами вы должны защищать сервер СУБД, канал до хоста сервисов (по сути всю локальную сеть) и сам хост.
G>>Это решается очень просто.

S>Предложите ваш проект для интрасети. Напомню, в исходной постановке вопроса всё равно требуется прямой доступ к СУБД.
Кому требуется, клиентским приложениям? Тогда у вас 100% жопа с безопасностью.
В 99.99% случаев требуется прослойка между БД и клиентом, хотябы такая сверхтонкая как Data Services.

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

S>Вы доверяете всей БЛ или у вас некие общие методы типа "проверь, могу ли я изменить себя", которые надо не забывать дёргать?
Для этого есть тесты.

S>Лукавите, ИМХО
Нет.


S>>>При этом товарищи, ответственные за сервисы будут орать "Уйди, ссуко! Так надо!", ибо так действительно надо и они вовек не поймут какого от них требуют безопасного кода, который мешает медитировать на священные потребности бизнеса, отныне и вовеки — трындец!
G>>Вы действительно работаете с такими людьми? Я в основном встречал адеквактных разработчиков, которые понимали в безопасности и знали зачем она нужна.
S>О тааа, что такое безопасность своих данных они понимали. Что если я им дам права на запись, их код сможет поломать чужую работу... не объяснить никогда
Как все плохо...

G>>Вообще не стоит свой негативный опыт выставлять как архитектурные проблемы.
S>Не надо. Этто очень позитивный опыт Очень быстро учишься видеть проблемы до того, как они придут. Или не учишься.
Исправляя проблемы, которых еще нет вы создаете огромный оверхед.
Если бы вы поработали над архитектурой вместе с теми, чей код сможет поломать чужую работу (с), то большенство ваших проблем и не вознило бы никогда.

S>Плиз, читайте внимательнее. Я по сути пишу третий раз одно и то же. Давайте действительно закончим.
По сути вы свои заблуждения выдаете за истину.

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

S>Ёк, шо ж так много-то??? Давайте по порядку.
да я и сам ужаснулся в дальнейшем буду лаконичен.

S>Ну и не используйте без защиты на уровне СУБД windows authentification или прямую sql авторизацию для пользователей. Им ничего не помешает подконнектиться напрямую и нагадить.
как ? ведь сиквел не доступен извне ?

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

S>Про сервисы и EF. Я вроде уже объяснял где-то, что при отсутствии контроля доступа никакие меры не спасут отца русской демократии И хоть обклейте сервер декларациями об ответственности, распоряжениями по личному составу и прочими бумажками — не спасёт это вас.
а как бороться с возможностью админов внедрить свой код ? все равно таблицу можно проапдейтить — он, в конце-концов, админ или кто? кроме как административного метода разруливания этим я другого не вижу... у вас есть решение ???

S>Я уже подустал вдалбливать элементарщину — чем проще система и чем меньше у неё периметр безопасности — тем она защищённей. В варианте с сервисами вы должны защищать сервер СУБД, канал до хоста сервисов (по сути всю локальную сеть) и сам хост. Вы должны отслеживать бизнес-логику на сервисе и убеждаться что она не открывает непредвиденный доступ к исходным данным. При этом товарищи, ответственные за сервисы будут орать "Уйди, ссуко! Так надо!", ибо так действительно надо и они вовек не поймут какого от них требуют безопасного кода, который мешает медитировать на священные потребности бизнеса, отныне и вовеки — трындец!

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

Гмм... ещё раз попробуем

2 gandjustas:

S>>Ну здесь накладные расходы будут как минимум сопоставимы. Ну и писалось уже, что датасеты хороши когда надо кэшить данные. Скажите честно, вы читаете только первые предложения из каждого абзаца?
G>Я все читаю, но датасеты всегда полностью передаются по сети (вместе со схемой и пр.). В Data Services вы передаете и получаете только необходимое. Причем схема данных не передается.

Вы знаете, датасеты умеют передавать pure xml (без схемы) и binary serialisation умеют. Но это наверное неправильные датасеты Но даже со схемой, поскольку вы передаёте данные скопом, а не подтягиваете по мере надобности, общая нагрузка на сеть будет меньше.

G>По вашему в реалворд системах каждый кто захочет лезет в базу? Это скорее исключение.
G>Опять-таки ваш опыт в данном случае очень субъективнен.

Ну вот смотрите. Мы говорим про интерпрайз систему. У неё есть внешние пользователи. Они ломятся к системе через сайт/службы. Есть внутренние пользователи. Они ломятся через десктопные программы/службы. Есть репорты, которые почти всегда ломятся напрямую к СУБД. Есть легаси системы и 1С. 1С работает, допустим через выгрузку по расписанию и Integration Services. Легаси системы стучатся через Linked Server. Заставить всю эту шоблу ломиться через прослойки — не важно что это будет (DCOM, вебсервисы, ваше собственное творение) — практически нереально.
Все требования к защите, тем не менее, никуда не исчезнут. Как можно их реализовать?

S>>Доступ к базе был из локальной сети. Хватило
G>Даже в локальной сети можно ограничить доступ в базу.
G>Это должно быть проблемой админа, а не программистов.
Неа Приложение работало почти целиком через вебсервисы. Строка соединения в датасете вообще не использовалась. Но! для репортов понадобился доступ к БД, поскольку структура отчёта динамически подгонялась под требования пользователя. Они решили пойти через генерацию SQL. Ну и открыли доступ. Как администратор может защитить ИХ сервер (за который ответственность несут разработчики, и они никого не пускает, потому как если делать как положено, половина систем сдыхает)?

S>>>>Скажите, у вас был опыт создания систем, в которых требовалась реальная защита данных? И не тупое "дать права на вьюху", а с разруливанием имеющихся разрешений, наследованием по иерархии, учётом состояния пользователя и расписания работы и с защитой на уровне отдельных атрибутов? Причём самой безопасностью должны были управлять поользователи, а не дядько сисадмин. Я уже не говорю о ситуации, когда данные нужны нескольким модулям и БЛ у них и близко не совпадает.
S>>>>Причём пользователи вполне были заинтересованы в вводе некорректных данных, и квалификация у "программистов-серкеташ" была достаточная. Плюс отдельные "секретарши" вполне могут просоциоинженериться до администратора домена и попытаться заломиться напрямую на СУБД.
G>>>Такое как раз решается на уровне сервера приложений, а доступ к БД открывается только серверу.
Епть. Смотрите. У нас есть некоторая система. Несколько клиентов-подсистем. За них вы не отвечаете и сделать с ними ничего не можете. Функционал (БЛ) клиентов не пересекается, но они работают с одними и теми же данными. Для каждого клиента представление данных своё. Надо гарантировать, что весь зоопарк ничего не порушит.
У вас не будет общих сущностей и общих вебсервисов — Ни структура данных, ни функционал не пересекаются. Единственный вариант — использовать некоторые воспомогательные функции проверки и дёргать их при каждом действии.
Если вы забыли дёрнуть проверку — у вас дыра в защите.

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

S>>Ребят, это, ёпть, сферический конь в вакууме. У вас сервер приложений умеет всё, что умеет СУБД?
G>Нет, а зачем? Он умеет столько сколько достаточно для решения бизнес задач.

S>>И даже тру транзакции?
G>Что такое тру транзакции? Если надо обрабатывать длительную бизнес-транзакцию, то это делается средствами, отличными от транзакций БД.

Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.

Естественно заказ должен быть атомарным, либо всё, либо ничего. И, поскольку заказ может быть отправлен внешней системой в ходе другой транзакции, нужна вложенность транзакций. Проводка заказов выливается в запросы к внешним системам — склад, CRM, бухгалтерия и т.п. Они тоже должны быть в транзакциях. Если хоть одно из звеньев цепочки не реализует WS-TX (или реализует своим особым способом) — увы...

Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).

S>>Предложите ваш проект для интрасети. Напомню, в исходной постановке вопроса всё равно требуется прямой доступ к СУБД.
G>Кому требуется, клиентским приложениям? Тогда у вас 100% жопа с безопасностью.
G>В 99.99% случаев требуется прослойка между БД и клиентом, хотябы такая сверхтонкая как Data Services.

Да-да?
Дальнейший флейм перенёс в священные войны [http://www.rsdn.ru/forum/message/3219133.aspx

Автор: Sinix
Дата: 18.12.08

].

G>По сути вы свои заблуждения выдаете за истину.
Может быть. Разубедите

2 Аноним:
S>>Ну и не используйте без защиты на уровне СУБД windows authentification или прямую sql авторизацию для пользователей. Им ничего не помешает подконнектиться напрямую и нагадить.
А>как ? ведь сиквел не доступен извне?
ниже

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

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

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

Уух... ребят. попробуйте повернуть мозги на 180 градусов — на позицию злонамеренного инсайдера или секретарши-студента, которому просто нех делать. И попробуйте найти точки, с которых ваше приложение могут поломать. Эти точки всё равно будут, знаете вы о них или нет. Если их скрывать — ситуация уже точно не улучшиться. В лучшем случае защищать надо только одну машину. В худшем всю сеть — сервис паки на машинах (ау, помните 2003 год и уязвимости с прямым доступом по RPC на 135,139,445 портах? Хорошо их оперативно прикрыли...), шифрование трафика, пароли админов и т.п. Дыра на любом участке убъёт вашу систему напрочь. Детальное обсуждение — в священных войнах [http://www.rsdn.ru/forum/message/3219133.aspx

Автор: Sinix
Дата: 18.12.08

].

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

S>Гмм... ещё раз попробуем

S>2 gandjustas:

S>>>Ну здесь накладные расходы будут как минимум сопоставимы. Ну и писалось уже, что датасеты хороши когда надо кэшить данные. Скажите честно, вы читаете только первые предложения из каждого абзаца?
G>>Я все читаю, но датасеты всегда полностью передаются по сети (вместе со схемой и пр.). В Data Services вы передаете и получаете только необходимое. Причем схема данных не передается.

S>Вы знаете, датасеты умеют передавать pure xml (без схемы) и binary serialisation умеют.
Без передачи схемы от датасетов толку мало. Даже бинарная реариализация не спасает, нельзя передать только необходимую часть датасета.

S>Но это наверное неправильные датасеты Но даже со схемой, поскольку вы передаёте данные скопом, а не подтягиваете по мере надобности, общая нагрузка на сеть будет меньше.
Проведите эксперимент, сколько будет трафика уходить за сеанс работы по сети с датасетами и Data Services.

G>>По вашему в реалворд системах каждый кто захочет лезет в базу? Это скорее исключение.
G>>Опять-таки ваш опыт в данном случае очень субъективнен.

S>Ну вот смотрите. Мы говорим про интерпрайз систему. У неё есть внешние пользователи. Они ломятся к системе через сайт/службы. Есть внутренние пользователи. Они ломятся через десктопные программы/службы. Есть репорты, которые почти всегда ломятся напрямую к СУБД. Есть легаси системы и 1С. 1С работает, допустим через выгрузку по расписанию и Integration Services. Легаси системы стучатся через Linked Server. Заставить всю эту шоблу ломиться через прослойки — не важно что это будет (DCOM, вебсервисы, ваше собственное творение) — практически нереально.
Все реально, было бы желание.

S>Все требования к защите, тем не менее, никуда не исчезнут. Как можно их реализовать?

S>>>Доступ к базе был из локальной сети. Хватило
G>>Даже в локальной сети можно ограничить доступ в базу.
G>>Это должно быть проблемой админа, а не программистов.
S>Неа Приложение работало почти целиком через вебсервисы. Строка соединения в датасете вообще не использовалась. Но! для репортов понадобился доступ к БД, поскольку структура отчёта динамически подгонялась под требования пользователя. Они решили пойти через генерацию SQL. Ну и открыли доступ. Как администратор может защитить ИХ сервер (за который ответственность несут разработчики, и они никого не пускает, потому как если делать как положено, половина систем сдыхает)?
Если у вас плохо с взаимодействием между разработчиками и админами, если не можете сделать отчеты через прослойку, то это не архитектурные проблемы.
Другие люди вполне смогут сделать отчеты через прослойку и им не понадобится городить кучу кода в БД.

S>Епть. Смотрите. У нас есть некоторая система. Несколько клиентов-подсистем. За них вы не отвечаете и сделать с ними ничего не можете. Функционал (БЛ) клиентов не пересекается, но они работают с одними и теми же данными. Для каждого клиента представление данных своё. Надо гарантировать, что весь зоопарк ничего не порушит.
Функционал должен быть на сервере, клиенты должны быть тонкими. Тогда ничего никто не порушит.

S>У вас не будет общих сущностей и общих вебсервисов — Ни структура данных, ни функционал не пересекаются. Единственный вариант — использовать некоторые воспомогательные функции проверки и дёргать их при каждом действии.
Тогда вам нужно несколько независимых "серверов" с различными наборавми сервисов.

S>Если вы забыли дёрнуть проверку — у вас дыра в защите.
Для этого есь тесты.

S>Сферический сценарий в вакууме: есть сервис "наградить подчинённого". Принимает ID подчинённого, награждает его если товарищ подчинён авторизовавшемуся товарищу. При очередном изменении логики награждения (выдаём не фарфоровых слоников, а шоколадную медальку) вы забыли дёрнуть эту самую проверку. У вас дырка. Но поскольку это дырка в относительно редко использующемся коде — допустим есть другой сервис "наградить всех подчинённых", который используется куда чаще, она остаётся неотслеженной. У вас безопасность системы будет зависеть от надёжности кода. Поверьте опыту, поломать декларативное описание, так чтобы всё продолжало работать, но появилась дырка куда сложнее. Поскольку это описание гарантированно используется в каждом сценарии шансы на обнаружение дырки тоже растут. Видите, ничего сложного
Используйте тестирование и будет вам счастье.

S>>>Ребят, это, ёпть, сферический конь в вакууме. У вас сервер приложений умеет всё, что умеет СУБД?
G>>Нет, а зачем? Он умеет столько сколько достаточно для решения бизнес задач.

S>>>И даже тру транзакции?
G>>Что такое тру транзакции? Если надо обрабатывать длительную бизнес-транзакцию, то это делается средствами, отличными от транзакций БД.

S>Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.
Одни вызов сервиса "разместить заказ", дальше пусть сервси внутри разбирается.

S>Естественно заказ должен быть атомарным, либо всё, либо ничего. И, поскольку заказ может быть отправлен внешней системой в ходе другой транзакции, нужна вложенность транзакций. Проводка заказов выливается в запросы к внешним системам — склад, CRM, бухгалтерия и т.п. Они тоже должны быть в транзакциях. Если хоть одно из звеньев цепочки не реализует WS-TX (или реализует своим особым способом) — увы...
См выше. Звено от клиента к серверу не поддерживает WS-TX, и ниче, работать будет.

S>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
От синхронной репликации через интернет загнется кто угодно.

Вообще старнно что вы отсутсвие нормальной архитектуры, остуствие взамодействия между группами и отсутствие тестирования пытаетесь заткнуть кучей кода в БД. При это выдавая такой путь как самый правильный.

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

S>>Вы знаете, датасеты умеют передавать pure xml (без схемы) и binary serialisation умеют.
G>Без передачи схемы от датасетов толку мало. Даже бинарная реариализация не спасает, нельзя передать только необходимую часть датасета.

Эммм... мы всё ещё обсуждаем реализацию внутреенностей системы?

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

S>>Епть. Смотрите. У нас есть некоторая система. Несколько клиентов-подсистем. За них вы не отвечаете и сделать с ними ничего не можете. Функционал (БЛ) клиентов не пересекается, но они работают с одними и теми же данными. Для каждого клиента представление данных своё. Надо гарантировать, что весь зоопарк ничего не порушит.
G>Функционал должен быть на сервере, клиенты должны быть тонкими. Тогда ничего никто не порушит.

S>>У вас не будет общих сущностей и общих вебсервисов — Ни структура данных, ни функционал не пересекаются. Единственный вариант — использовать некоторые воспомогательные функции проверки и дёргать их при каждом действии.
G>Тогда вам нужно несколько независимых "серверов" с различными наборавми сервисов.

Да. Вы предлагаете дублировать проверку доступа, или создать ещё один промежуточный уровень?

S>>Если вы забыли дёрнуть проверку — у вас дыра в защите.
G>Для этого есть тесты.
Тесты есть, их не может не есть. Но скажите пожалуйста, чем вы проверите корректность самого теста?

S>>Сферический сценарий в вакууме: есть сервис "наградить подчинённого". Принимает ID подчинённого, награждает его если товарищ подчинён авторизовавшемуся товарищу. При очередном изменении логики награждения (выдаём не фарфоровых слоников, а шоколадную медальку) вы забыли дёрнуть эту самую проверку. У вас дырка. Но поскольку это дырка в относительно редко использующемся коде — допустим есть другой сервис "наградить всех подчинённых", который используется куда чаще, она остаётся неотслеженной. У вас безопасность системы будет зависеть от надёжности кода. Поверьте опыту, поломать декларативное описание, так чтобы всё продолжало работать, но появилась дырка куда сложнее. Поскольку это описание гарантированно используется в каждом сценарии шансы на обнаружение дырки тоже растут. Видите, ничего сложного
G>Используйте тестирование и будет вам счастье.
// Сорри стебаюсь. Просьба коммент не учитывать.
Вы можете гарантировать, что все потенциально небезопасные методы будут проверены именно на эту уязвимость?

S>>Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.
G>Одни вызов сервиса "разместить заказ", дальше пусть сервси внутри разбирается.
Ещё раз. Сервис может колбасить внутри себя вызовы к внешним системам, которые тоже применяют транзакции...
Эти вызовы не держат транзакции. В одном из них произошла ошибка и он тихо сдох. Данные рассогласованы и вы этого не узнаете без специальной проверки.

S>>Естественно заказ должен быть атомарным, либо всё, либо ничего. И, поскольку заказ может быть отправлен внешней системой в ходе другой транзакции, нужна вложенность транзакций. Проводка заказов выливается в запросы к внешним системам — склад, CRM, бухгалтерия и т.п. Они тоже должны быть в транзакциях. Если хоть одно из звеньев цепочки не реализует WS-TX (или реализует своим особым способом) — увы...
G>См выше. Звено от клиента к серверу не поддерживает WS-TX, и ниче, работать будет.
См выше Если клиент обращается к вашему сервису внутри транзакции и ваш сервис сдохнет, он повредит уже свои данные

S>>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
G>От синхронной репликации через интернет загнется кто угодно.
Ну не надо, что ж вы так... Вполне осуществимая вешь.

G>Вообще старнно что вы отсутсвие нормальной архитектуры, остуствие взамодействия между группами и отсутствие тестирования пытаетесь заткнуть кучей кода в БД. При это выдавая такой путь как самый правильный.

Уххх. С чего вы взяли, что у меня нет ни архитектуры, ни взаимодействия между группами, ни тестирования? Есть всё это. Просто есть ещё и внешняя среда, которая [censored] на все ваши решения.

Кстати, если не помните, я никогда не предлагал запихнуть ВСЮ БЛ в субд, а исключительно представление данных и контроль доступа к ним — то, что СУБД в принципе умеет гораздо лучше любого велосипеда.

// Кажется, пошёл переход на личности. Извиняюсь если задел. Замнём?

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

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

S>>>У вас не будет общих сущностей и общих вебсервисов — Ни структура данных, ни функционал не пересекаются. Единственный вариант — использовать некоторые воспомогательные функции проверки и дёргать их при каждом действии.
G>>Тогда вам нужно несколько независимых "серверов" с различными наборавми сервисов.

S>Да. Вы предлагаете дублировать проверку доступа, или создать ещё один промежуточный уровень?
Проверка доступа разграничивает бизнес-функции, такие проверки отлчно живут в самих сервисах, эти проверки не пересекаются друг с другом.
Например есть функция F1, которая вызывает действия A, B, C. Если пользователю запрещено действие A, то ему фактически запрещена функция F1.
Кроме того разрешение\запирещение некоторых действий может зависить от того в какой функции они вызываются.
Разграничение доступа на уровне функций оказывается облее гибким и реализуется проще.

S>>>Если вы забыли дёрнуть проверку — у вас дыра в защите.
G>>Для этого есть тесты.
S>Тесты есть, их не может не есть. Но скажите пожалуйста, чем вы проверите корректность самого теста?
А чем вы докажете крорректность проверок в БД?
Не надо детский сад разводить. Тесты обычно достстаточно просты чтобы их можно было проанализировать.

S>>>Сферический сценарий в вакууме: есть сервис "наградить подчинённого". Принимает ID подчинённого, награждает его если товарищ подчинён авторизовавшемуся товарищу. При очередном изменении логики награждения (выдаём не фарфоровых слоников, а шоколадную медальку) вы забыли дёрнуть эту самую проверку. У вас дырка. Но поскольку это дырка в относительно редко использующемся коде — допустим есть другой сервис "наградить всех подчинённых", который используется куда чаще, она остаётся неотслеженной. У вас безопасность системы будет зависеть от надёжности кода. Поверьте опыту, поломать декларативное описание, так чтобы всё продолжало работать, но появилась дырка куда сложнее. Поскольку это описание гарантированно используется в каждом сценарии шансы на обнаружение дырки тоже растут. Видите, ничего сложного
G>>Используйте тестирование и будет вам счастье.
S>// Сорри стебаюсь. Просьба коммент не учитывать.
S>Вы можете гарантировать, что все потенциально небезопасные методы будут проверены именно на эту уязвимость?
Да. Для этого тестирование и применяется.

S>>>Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.
G>>Одни вызов сервиса "разместить заказ", дальше пусть сервси внутри разбирается.
S>Ещё раз. Сервис может колбасить внутри себя вызовы к внешним системам, которые тоже применяют транзакции...
S>Эти вызовы не держат транзакции. В одном из них произошла ошибка и он тихо сдох. Данные рассогласованы и вы этого не узнаете без специальной проверки.
В общем случае получается Задача двух генералов, которая без промежуточной надежной службы не решается.
Во-первых можно использовать Reliable messaging как MSMQ.
Во-вторых можно использовать компенсационные действия в случае неуспеха одной из операций, чтобы свести к минимум вероятность рассогласовния данных.
А по-хорошему надо настраивать управляемую синхронизацию между между базами.

S>>>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
G>>От синхронной репликации через интернет загнется кто угодно.
S>Ну не надо, что ж вы так... Вполне осуществимая вешь.
В локальной сети да, через инет, в случае 2-3 реплик уже слишком медленно работает. При этом все это жутко нерасширяемо.

G>>Вообще старнно что вы отсутсвие нормальной архитектуры, остуствие взамодействия между группами и отсутствие тестирования пытаетесь заткнуть кучей кода в БД. При это выдавая такой путь как самый правильный.

S>Уххх. С чего вы взяли, что у меня нет ни архитектуры, ни взаимодействия между группами, ни тестирования?
Из ваших рассказов.

S>Просто есть ещё и внешняя среда, которая [censored] на все ваши решения.
С внешней средой надо договариваться, а не давать прямой доступ к базе.

S>Кстати, если не помните, я никогда не предлагал запихнуть ВСЮ БЛ в субд, а исключительно представление данных и контроль доступа к ним — то, что СУБД в принципе умеет гораздо лучше любого велосипеда.
Вы рассказываете про контроль достпу к функциям системы, при этом пытаетесь такие задачи решать контролем доступа к данным.
Это неправльный путь.

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

Разделение привилегий на чтение через хранимки не очень понятно. Как выглядят row level security (с логикой сложнее чем where t.owner=user) & column level security реализованные на хранимках? Что-то мне подсказывает, что с декларативностью мы тут пролетаем.

Как реализовать проверку привилегий для следующего сценария: сущности заказ-позиции, заказ могут создавать все менеджеры, редакитровать позиции могут только старшие менеджеры? Какие хранимки нам потребуются, какой интерфейс они будут иметь, каким группам будут выданы привилегии на их выполнение?

Декларативность схемы авторизации для апп сервера довольно просто реализовать. Степень декларативности будет как минимум не хуже списка grant execute on xxx to xxx. Самое приятное в этом, что при желании мы сможем расширять DSL, например ограничениями на входные параметры, чего нельзя сделать в базе.

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

Про транзакционность я вообще ничего не понял, чем транзакция клиента + ХП лучше транзакции сервера без ХП?

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

S>>>>Нет. Я не про длительные автономные транзакции. Я про чуть другое. Допустим, у нас идёт оформление заказа. Заказ представляет из себя заголовок — ссылку на заказчика, дату заказа и т.п. — и собсно заказанные услуцги, товары — не суть важно.
G>>>Одни вызов сервиса "разместить заказ", дальше пусть сервси внутри разбирается.
S>>Ещё раз. Сервис может колбасить внутри себя вызовы к внешним системам, которые тоже применяют транзакции...
S>>Эти вызовы не держат транзакции. В одном из них произошла ошибка и он тихо сдох. Данные рассогласованы и вы этого не узнаете без специальной проверки.
G>В общем случае получается Задача двух генералов, которая без промежуточной надежной службы не решается.
G>Во-первых можно использовать Reliable messaging как MSMQ.
G>Во-вторых можно использовать компенсационные действия в случае неуспеха одной из операций, чтобы свести к минимум вероятность рассогласовния данных.
G>А по-хорошему надо настраивать управляемую синхронизацию между между базами.

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

я смотрю что вопрос CRUD в EF и целесообразность для него хранимок перерос в вопрос где размещать слой бизнес логики

2 gandjustas:

S>>К щастью, к тому случаю я не имею никакого отношения.
G>К вашему несчастью не имеете. Если все пустить через сервсиы, и не давать доступа к БД, то куча кода в БД станет ненужной.
[Ctnsored], [censored], [censored]! Был приведён пример, к чему могут привести сквозные дыры при вашем подходе. Я никаким боком в этом примере не участвовал — и слава богу, повесился бы со стыда. Но фигурально

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

G>Например есть функция F1, которая вызывает действия A, B, C. Если пользователю запрещено действие A, то ему фактически запрещена функция F1.
G>Кроме того разрешение\запирещение некоторых действий может зависить от того в какой функции они вызываются.
G>Разграничение доступа на уровне функций оказывается облее гибким и реализуется проще.
Ага. Понял к чему вы клоните. К запрету нескольких базовых действий, всё остальное работает через них — получает запрет. Так?

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

S>>Тесты есть, их не может не есть. Но скажите пожалуйста, чем вы проверите корректность самого теста?
G>А чем вы докажете крорректность проверок в БД?
G>Не надо детский сад разводить. Тесты обычно достстаточно просты чтобы их можно было проанализировать.
// Не буду стебаться. На этот раз удержался.

S>>Вы можете гарантировать, что все потенциально небезопасные методы будут проверены именно на эту уязвимость?
G>Да. Для этого тестирование и применяется.
Понимаете в чём дело. При таком подходе безопасность системы гарантируется только корректностью ваших тестов. Ещё Дейкстра писал, что тесты не гарантируют надёжность системы. Они только показывают возможность её работоспособности и только в определённых условиях.

G>В общем случае получается Задача двух генералов, которая без промежуточной надежной службы не решается.
G>Во-первых можно использовать Reliable messaging как MSMQ.
G>Во-вторых можно использовать компенсационные действия в случае неуспеха одной из операций, чтобы свести к минимум вероятность рассогласовния данных.
G>А по-хорошему надо настраивать управляемую синхронизацию между между базами.

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

S>>>>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
G>>>От синхронной репликации через интернет загнется кто угодно.
S>>Ну не надо, что ж вы так... Вполне осуществимая вешь.
G>В локальной сети да, через инет, в случае 2-3 реплик уже слишком медленно работает. При этом все это жутко нерасширяемо.
Увы-увы Для медленных каналов можно в принципе сделать merge репликацию. Но всё-таки, согласитесь, лучше чем через веб-сервисы, а?

S>>Уххх. С чего вы взяли, что у меня нет ни архитектуры, ни взаимодействия между группами, ни тестирования?
G>Из ваших рассказов.
Сорри. Слишком заострял вимание на негативных моментах.

S>>Просто есть ещё и внешняя среда, которая [censored] на все ваши решения.
G>С внешней средой надо договариваться, а не давать прямой доступ к базе.
Угу

S>>Кстати, если не помните, я никогда не предлагал запихнуть ВСЮ БЛ в субд, а исключительно представление данных и контроль доступа к ним — то, что СУБД в принципе умеет гораздо лучше любого велосипеда.
G>Вы рассказываете про контроль достпу к функциям системы, при этом пытаетесь такие задачи решать контролем доступа к данным.
G>Это неправльный путь.

[Censored]!
Насколько помню, я нигде не говорил, про контроль доступа к функциям системы. Я говорил про представление данных и контроль доступа к ним. Если был не так понят — извините.

2 Ziaw:
Не так легко объяснить на пальцах, но попробую. Обычно просто пишется view, который к полям сущности добавляет bitmask операций для текущего пользователя. Далее в хранимках в запросе делается побитовое И битовой маски сущности и битовой маски запрашиваемых разрешений. Это если примитивно и без учёта всяких аццких оптимизаций.
Для примера с заказами/details — по три (четыре, если можем обновлять) хранимки на каждую сущность и одно представление на каждую сущность (если так хочется, можно тупо скопировать запрос из вьюхи внутрь каждой хранимки).
Если у вас другое приложение, которое требует другого представления заказов/details'ov (без крыльев и с перламутровыми пуговицами), вы просто добавляете три (четыре) хранимки, которые ссылаются на соответствующий view.
Разумеется, API каждого приложения разносится по разным схемам, разрешения — по разным ролям, пользователи добавляются в эти роли.

Повторюсь, в реальности всё несколько сложнее, но число воспомогательных элементов стремится к константе.

Про транзакционность — флейм ушёл в сторону. Теперь спорим ещё и о транзакциях и тестировании. Скоро будем обсуждать мирукапец.

2 Аноним:
Да флейм ушёл в сторону, вынос в другую ветку не помог Кстати, посмотрите (я давал ссылку выше), там меня определённо побеждают На редкость адекватный холивар пока складывается.

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

G>>Например есть функция F1, которая вызывает действия A, B, C. Если пользователю запрещено действие A, то ему фактически запрещена функция F1.
G>>Кроме того разрешение\запирещение некоторых действий может зависить от того в какой функции они вызываются.
G>>Разграничение доступа на уровне функций оказывается облее гибким и реализуется проще.
S>Ага. Понял к чему вы клоните. К запрету нескольких базовых действий, всё остальное работает через них — получает запрет. Так?
Нет, я как раз говорю о наложении ограничений на высокоуровневые функции. Низлежащие проверки в таком случае не нужны, но это при условии того, что никто не вызывает и не может вызвать низкоуровневые функции.

S>>>Вы можете гарантировать, что все потенциально небезопасные методы будут проверены именно на эту уязвимость?
G>>Да. Для этого тестирование и применяется.
S>Понимаете в чём дело. При таком подходе безопасность системы гарантируется только корректностью ваших тестов. Ещё Дейкстра писал, что тесты не гарантируют надёжность системы. Они только показывают возможность её работоспособности и только в определённых условиях.
Во времена Дейкстры дисциплины тестирования ПО еще не было. Если вы сделаете защиту кода декларативной (например через атрибуты в C#), то вам даже не придется тестировать защиту отдельных методов, вам достаточно будет протестировать работу механизма проверки ограничений и удостовериться что все высокоуровневые функции вызываются через этот механизм.
Это горздо проще, чем доказать корректность всяческих проверок в БД, написанных на SQL, которые в большенстве случаев даже протестировать нельзя.


G>>В общем случае получается Задача двух генералов, которая без промежуточной надежной службы не решается.
G>>Во-первых можно использовать Reliable messaging как MSMQ.
G>>Во-вторых можно использовать компенсационные действия в случае неуспеха одной из операций, чтобы свести к минимум вероятность рассогласовния данных.
G>>А по-хорошему надо настраивать управляемую синхронизацию между между базами.

S>Угу. Вот мы и пришли к распределённым транзакциям. Насколько я понимаю, они подерживаются только ограниченным набором хостов, например, WCF их помнится держит. Если вам не повезло, и сторонняя система их не держит — извините. Понимаете, веб-сервисы не панацея. Они страдают от тех же проблем взаимодействия, что и СУБД. ТОлько в случае СУБД эти проблемы решаются прямо из коробки (для большей части вендоров).
Если сторонняя система не поддерживает транзакции, то как эту проблему решает СУБД?


S>>>>>Не забываем, что веб-вервисы — очень тяжёлый протокол, и при активном обмене данными ваша система может просто загнуться. Напоследок. Вы замучаетесь синхронно реплицироваться через вебсервисы (пример — данные филиала одновременно заносятся и у них и в центральном офисе).
G>>>>От синхронной репликации через интернет загнется кто угодно.
S>>>Ну не надо, что ж вы так... Вполне осуществимая вешь.
G>>В локальной сети да, через инет, в случае 2-3 реплик уже слишком медленно работает. При этом все это жутко нерасширяемо.
S>Увы-увы Для медленных каналов можно в принципе сделать merge репликацию. Но всё-таки, согласитесь, лучше чем через веб-сервисы, а?
Что лучше? Веб-сервисы — более высокий уровень абстракции, чем БД. Пока этого не поймете толку вам от сервисов не будет.

S>>>Кстати, если не помните, я никогда не предлагал запихнуть ВСЮ БЛ в субд, а исключительно представление данных и контроль доступа к ним — то, что СУБД в принципе умеет гораздо лучше любого велосипеда.
G>>Вы рассказываете про контроль достпу к функциям системы, при этом пытаетесь такие задачи решать контролем доступа к данным.
G>>Это неправльный путь.

S>[Censored]!
S>Насколько помню, я нигде не говорил, про контроль доступа к функциям системы. Я говорил про представление данных и контроль доступа к ним. Если был не так понят — извините.
Еще раз. Если у вас полностью контролируется доступ к высокоуровневым функциям и все действия могут производиться только (!) через них, то вам контроль доступа к данным не нужен (если это только не Row Level Security).

Ваши все примеры показывают что как раз система хреново спроектирована. Каждый внешний компонент обращается к той части системы, к которой удобно.
У вас сильно нарушена инкапсуляция. Поэтому требуется защита на всех уровнях.

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

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

G>Нет, я как раз говорю о наложении ограничений на высокоуровневые функции. Низлежащие проверки в таком случае не нужны, но это при условии того, что никто не вызывает и не может вызвать низкоуровневые функции.
Ага. Я вас всё-таки не понимаю Согласитесь, что высокоуровневых функций будет больше, и что проверка разрешений, получается, будет мешаться вместе с БЛ.

G>... Если вы сделаете защиту кода декларативной (например через атрибуты в C#), то вам даже не придется тестировать защиту отдельных методов, вам достаточно будет протестировать работу механизма проверки ограничений и удостовериться что все высокоуровневые функции вызываются через этот механизм.
Согласен. Но у вас реально получается, что чтобы защитить доступ к конкретному набору сущностей, вам придётся заводить отдельный атрибут или enum, который будет храниться в атрибуте. Громоздко, не находите?

G>Это горздо проще, чем доказать корректность всяческих проверок в БД, написанных на SQL, которые в большенстве случаев даже протестировать нельзя.
Спорно. Но не будем

S>>Угу. Вот мы и пришли к распределённым транзакциям. Насколько я понимаю, они подерживаются только ограниченным набором хостов, например, WCF их помнится держит. Если вам не повезло, и сторонняя система их не держит — извините. Понимаете, веб-сервисы не панацея. Они страдают от тех же проблем взаимодействия, что и СУБД. ТОлько в случае СУБД эти проблемы решаются прямо из коробки (для большей части вендоров).
G>Если сторонняя система не поддерживает транзакции, то как эту проблему решает СУБД?
Никак. Просто шансы, что транзакции будут, если у нас обе стороны — СУБД — максимальны. ИМХО, мы ушли уже куда-то совсем в сторону...


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

S>>[Censored]!
S>>Насколько помню, я нигде не говорил, про контроль доступа к функциям системы. Я говорил про представление данных и контроль доступа к ним. Если был не так понят — извините.
G>Еще раз. Если у вас полностью контролируется доступ к высокоуровневым функциям и все действия могут производиться только (!) через них, то вам контроль доступа к данным не нужен (если это только не Row Level Security).
Ух... раз вы так считаете... //где-то выше мы вроде пришли к выводу вроде говорили что надо подымать прямую репликацию между СУБД.

G>Ваши все примеры показывают что как раз система хреново спроектирована. Каждый внешний компонент обращается к той части системы, к которой удобно.
G>У вас сильно нарушена инкапсуляция. Поэтому требуется защита на всех уровнях.
Ёк... Раз переходим на личности, то у _меня_ защита на _одном_ уровне! //воспринимать только как стёб

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

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

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

G>>Нет, я как раз говорю о наложении ограничений на высокоуровневые функции. Низлежащие проверки в таком случае не нужны, но это при условии того, что никто не вызывает и не может вызвать низкоуровневые функции.
S>Ага. Я вас всё-таки не понимаю Согласитесь, что высокоуровневых функций будет больше, и что проверка разрешений, получается, будет мешаться вместе с БЛ.
Как раз наоборот. Высокоуровневых функций получается примерно в два раза меньше сущностей в БД.
Кроме того вам надо будет заводить по 4 и боолее проверок в БД на каждую сущность.
То есть проверок в примерно в 8 раз меньше.
В высокоуровневом коде проверки можно сделать декларативными (буквально один атрибут на методе\классе и не надо лезть в БД чтобы выяснить что операцию нельзя выполнить.

G>>... Если вы сделаете защиту кода декларативной (например через атрибуты в C#), то вам даже не придется тестировать защиту отдельных методов, вам достаточно будет протестировать работу механизма проверки ограничений и удостовериться что все высокоуровневые функции вызываются через этот механизм.
S>Согласен. Но у вас реально получается, что чтобы защитить доступ к конкретному набору сущностей, вам придётся заводить отдельный атрибут или enum, который будет храниться в атрибуте. Громоздко, не находите?
Давайте сравним. Мне в веб-сервисе надо повесить на защищаемый метод атрибут
[PrincipalPermissionAttribute(SecurityAction.Demand, Role="Supervisor")]
И в констркторе написать Thread.CurrentPrincipal = HttpContext.Current.User;
Все.

Покажите ваш код проверок в БД.

Конечно в более сложных случаях надо свои атрибуты писать и с помощью АОП оборачивать классы для проверок атрибутов безопасности, но декларативность никуда не денется.
Хотя в подобных по сложности сценариях на БД организовать защиту гораздо сложнее, чем атрибутов написать.


G>>Это горздо проще, чем доказать корректность всяческих проверок в БД, написанных на SQL, которые в большенстве случаев даже протестировать нельзя.
S>Спорно. Но не будем
В каком месте спорно? Хотите сказать что SQL тестировать легче чем код на C# или другом высокоуровневом языке?

S>>>Угу. Вот мы и пришли к распределённым транзакциям. Насколько я понимаю, они подерживаются только ограниченным набором хостов, например, WCF их помнится держит. Если вам не повезло, и сторонняя система их не держит — извините. Понимаете, веб-сервисы не панацея. Они страдают от тех же проблем взаимодействия, что и СУБД. ТОлько в случае СУБД эти проблемы решаются прямо из коробки (для большей части вендоров).
G>>Если сторонняя система не поддерживает транзакции, то как эту проблему решает СУБД?
S>Никак. Просто шансы, что транзакции будут, если у нас обе стороны — СУБД — максимальны. ИМХО, мы ушли уже куда-то совсем в сторону...
Это вообще вопрос администрирования. Для репликации можно создать отдельного пользователя, с отдельным Endpoint, который может заходить только по VPN подключению c сервера с другой БД.

S>>>Увы-увы Для медленных каналов можно в принципе сделать merge репликацию. Но всё-таки, согласитесь, лучше чем через веб-сервисы, а?
G>>Что лучше? Веб-сервисы — более высокий уровень абстракции, чем БД. Пока этого не поймете толку вам от сервисов не будет.
S>Прямая репликация эффективней, чем синхронизация через веб-сервисы. Не согласны?
Что значит "эффективней"? Если у вас две одинаковые СУБД в разных местах, то смотрите выше.
Если надо синхронизироваться между базами разного происхождения (например MS SQL Server и 1C), то лучше это делать через сервисы, надежно защищенные сертификатами.
Причем тут ХП и прочая муть?