WCF Data Services, потребляющие данные из хранилища на базе EF

Question

У нас есть существующий репозиторий, основанный на EF4/POCO и хорошо работающий. Мы хотим добавить сервисный уровень с помощью служб данных WCF и искать рекомендации по наилучшей практике.

До сих пор мы разработали класс, обладающий свойством IQueryable, а getter запускает метод репозитория «получить все пользователи». Проблема до сих пор была двукратной:

1) Нам потребовалось украсить поле идентификатора объекта poco, чтобы сообщить службе данных, какое поле было идентификатором. Это означает, что наш объект POCO не является «чистым».

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

Я сейчас остановил этот подход, и я думаю, что, возможно, нам стоит выставить OBjectContext из репозитория и использовать более «автоматическую» функциональность EF.

У кого-нибудь есть какие-либо советы или примеры использования шаблона репозитория с помощью служб передачи данных WCF?

Answer 1

Я думаю, что это вопрос прагматичности. Украшает ли POCO что-нибудь еще? Если нет, возможно, это лучший способ сделать это.

WCF Data Services и oData являются довольно новыми, я также искал руководство и кажется немного тонким.

Answer 2

Можете ли вы расширить немного больше того, что вы хотите выставить, и кто будет его использовать?

Вопросы, которые я видел до сих пор в нашем проекте

• Имея в MyRepository: ObjectContext и MyDataService: DataService разделяет логику, поэтому мы создали помощников. Я полагаю, что мы могли бы унаследовать репозиторий, хотя (в буквальном смысле это только что я придумал!)
• Перехватчики запросов и изменений - ваши друзья, но должен делегировать помощникам (или базовому классу), чтобы обеспечить DRY. то есть - если хранилище уже было GetAllUsers, и делает логику, что myservice.svc/Пользователи не обрабатывают, вам могут понадобиться осуществить запрос, перехватчика сделать фильтрацию - снова DRY означает помощник (или базовый метод), что и репозиторий и перехватчик могут использовать .
• совместимость asp.net позволяет задействовать в красиво аутентификации/авторизации - в запросе перехватчик, это хороший способ гарантировать, что Вы позволили увидеть только вещи вы позволили увидеть.

пару ловушек ....

1. Если это Flash/Flex на основе вы , вероятно, имеют проблемы с Flash/Flex не будучи в состоянии использовать HTTP PUT/MERGE или DELETE ,Вы получаете около это с помощью рентгеновского HTTPMethod-переопределение

2. Если это JavaScript/JQuery, сделать , что вы включаете JSON

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