Пользовательские классы ADO.NET Entity Framework - правильный выбор?

Question

У меня есть предстоящее требование, и я не уверен, что EF - правильный подход.

По сути, у меня есть контракт веб-службы для реализации, в котором есть несколько методов, которые возвращают определенные классы (классы DataContract со свойствами DataMember, поэтому они сериализуются правильно). Данные, которые составляют классы, будут результатом запросов к базе данных бэкэнда.

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

Мне интересно, могу ли я использовать ADO.NET Entity Framework для этого, однако я понимаю, что это создает классы Entity из таблиц базы данных. Мои пользовательские классы не похожи ни на одну из таблиц базы данных. Хранимые процедуры выполняют агрегирование и объединение таблиц для создания классов.

Я что-то здесь упускаю из того, что возможно с EF? Или мне лучше просто использовать хранимые процедуры / вручную подключать пользовательские классы на уровне данных?

Веб-служба будет размещаться в SharePoint 2010, поэтому я ограничен ASP.NET 3.5. Я думаю, что я буду использовать Шаблоны и Практики для доступа к слою данных, если только не появятся лучшие идеи.

Answer 1

Учитывая, что вы указали, что можете использовать только .NET 3.5, вы будете использовать EF 1.x, который не был широко принят в сообществе ORM .EF 4.x значительно улучшен, но, к сожалению, требует .NET 4.

DAAB, безусловно, является альтернативой, но вам все равно потребуется отобразить объекты Service из данных (т. Е. DAAB не является ORM)

IMO EF вступает в свои права при использовании с LINQ, особенно при использовании с запросами - если вы обнаружите, что пишете много SPROC в форме GetXXXByYYY (или используете много специальных или динамических sp_executesql) для заполнения вашегосущностей, тогда ORM с поддержкой LINQ имеет большой смысл.Однако, если у вас есть только несколько сильнодействующих PROC, которые имеют четко определенные интерфейсы, то ORM может быть излишним.

Answer 2

Если объектная модель вашего приложения заметно отличается от модели данных в вашей базе данных, то я бы придерживался классических хранимых процедур ADO.Net + для агрегирования и объединения таблиц.Мое мнение таково, что в таком случае любая ORM приносит больше проблем, чем пользы.