контролировать видимость полей для каждого экземпляра сущности с помощью WCF Data Service и Entity Framework - PullRequest
0 голосов
/ 12 января 2012

В качестве примера, скажем, у нас есть объект User с 10 полями, в котором хранятся такие вещи, как имя, фамилия, адрес электронной почты, телефон и т. Д.Четыре поля будут общедоступны, а для остальных шести потребуется авторизованная подписка (например, два пользователя отмечены как друзья).

При опросе службы данных таким образом: http://example.com/users?auth_token=xxx, запрашивающая сторона должнаувидеть поля, к которым он имеет доступ для каждого пользователя.Это очень похоже на то, как работает API Facebooks.

Я прошел через все трудности при написании собственного провайдера данных для WCF и понял, что он применяет мои правила ко всей коллекции.Что мне нужно, так это набор правил для каждого элемента в коллекции.Я думал о записи хуков в WCF для преобразования объекта Message, переданного обратно, но я чувствую, что с ним могут быть связаны слишком большие издержки.

У кого-нибудь есть идеи о том, что можно сделать?Или даже другой подход для удовлетворения моих потребностей?

1 Ответ

2 голосов
/ 12 января 2012

Это как бы против идеи WCF DS и OData.В OData вы определяете модель (EDM), в которой каждый объект имеет определенный набор свойств.Ожидается, что все экземпляры этого типа имеют все эти свойства.Вы можете использовать открытые типы (пометить тип объекта как открытый), чтобы добавить дополнительные свойства, которые являются необязательными (для каждого экземпляра), но тогда их не будет в модели.

Обычно это решается в одном из двухспособы:

1) Разделить сущность на два типа сущностей.«Публичный», который может видеть каждый, и «частный», который могут видеть только авторизованные пользователи.И иметь свойство навигации между публичным и частным.В этом случае вы даже можете скрыть всю частную сущность от неавторизованных пользователей, чтобы она не была видна даже в модели.(это очень безопасно и все еще полностью определено в модели).

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

С помощью специального провайдера вы также можете реализовать что-то еще, пользовательские провайдеры могут изменять модель для каждого запроса.Таким образом, в случае неавторизованного пользователя вы заставляете тип иметь открытые свойства, а в авторизованном случае вы делаете тип имеющим все свойства.Но затем он применяется ко всем экземплярам этого типа в этом одном запросе (позволяют ли оба варианта # 1 и # 2, описанные выше, делать это для баз каждого экземпляра, если вам действительно нужно).Это может быть так же безопасно, как # 1, и все еще статически типизировано, но это более запутанно, поскольку клиенты обычно не ожидают, что типы изменятся от запроса к запросу.

...