Entity Framework только с хранимыми процедурами

Question

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

Мы планируем создать N-уровневый архитектор с уровнем UI, BusinessLayer (BLL), DataAccessLayer (DAL) и BusinessObjectDefinitions (BOD). Уровень BOD известен всем другим уровням, и результаты выполнения запросов в DAL должны быть преобразованы в объекты (определенные в BOD) перед передачей в BLL.

Мы будем использовать хранимые процедуры только для всех методов CRUD. Таким образом, в случае хранимой процедуры выбора, мы добавим импорт функции, создадим сложный тип, а когда мы выполним функцию, мы преобразуем значения сложного типа в класс BOD и передадим его в BLL. Итак, по сути, у нас нет сущностей в модели, только сложные типы, которые преобразуются в бизнес-объекты.

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

Или я совершенно не прав?

Answer 1

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

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

Чтобы вставить / обновить данные с помощью petapoco, вам нужно вручную вызвать хранимую процедуру вставки / обновления, используя:

db.Execute("EXEC spName @param1 = 1, @param2 = 2")

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

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

Теперь сравните это с каркасом сущности: в EF я просто отобразил бы свою хранимую процедуру на мою сущность в edmx. Существует меньше риска опечатки, так как инструменты структуры сущностей будут автоматически генерировать отображение, анализируя мою хранимую процедуру.

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

entities.SaveChanges()

Answer 2

Я бы не использовал EF, если бы все, что я только что использовал, было сохраненным процессом.

Лично я бы посмотрел на что-то вроде PetaPoco, Massive или даже просто Ado.Net

.

EDIT

Вот пример того, как PetaPoco использует SP и выводит пользовательские типы

http://weblogs.asp.net/jalpeshpvadgama/archive/2011/06/20/petapoco-with-stored-procedures.aspx

Answer 3

Я согласен, если вы полагаетесь на хранимые процедуры для всех методов CRUD, тогда нет необходимости использовать EF.

Answer 4

Я использую EF для отображения вызовов хранимых процедур в качестве нашего DAL.Это экономит время при написании вашего DAL путем сопоставления функций.Мы не так часто используем LINQ to SQL, поскольку наш администратор БД не хочет прямого доступа к таблице данных.