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

Question

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

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

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

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

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

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

Answer 1

Учитывая, что вы указали, что можете использовать только .NET 3.5, вы будете использовать EF 1.x, который wasn't widely accepted in the ORM community. EF 4.x значительно улучшилось, но, к сожалению, требует .NET 4.

DAAB, безусловно, является альтернативой, но вы все равно должны планировать свои объекты службы из данных (т.е. DAAB не ОРМ)

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

Answer 2

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