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