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

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

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

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

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

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

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