Как я могу настроить OData и EF без привязки к моей структуре базы данных?

Question

Мне очень нравится OData (WCF Data Services).В прошлых проектах я кодировал так много Web-сервисов, просто чтобы по-разному читать мои данные.

OData дает клиентам большую гибкость в получении данных по мере необходимости.

Однако в сегодняшнем обсуждении коллега отметил, что то, как мы работаем с OData, - это не более, чем предоставление клиентскому приложению подключения к базе данных.

Вот как мы настраиваем нашу службу данных WCF.(Примечание: это традиционный способ)

1. Создание модели данных Entity Framework (E) F нашей базы данных
2. Публикация этой модели с помощью служб данных WCF
3. Добавление защиты в канал OData
   (это лучше, чем прямое подключение к SQL Server)

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

EF предлагает некоторую гибкость в отношении представления ваших данных и может использоваться для скрытия некоторых незначительных изменений в базе данных, которые не влияютклиентские приложения.Но я обнаружил, что это довольно ограничено.(См. этот пост для примера.) Я обнаружил, что шаблоны POCO (хотя и позволяют разделять модель и сущности) также не обладают большой гибкостью.

Итак,вопрос: что мне сказать моему коллеге?Как настроить службы данных WCF таким образом, чтобы они использовали бизнес-ориентированные контракты (как если бы в каждой операции чтения использовалась стандартная служба на основе WCF Soap)?

Просто чтобы прояснить ситуацию, позвольте мне спросить об этом по-другому.Как я могу отделить EF от WCF Data Services.Я в порядке, чтобы составить свои собственные контракты и использовать AutoMapper для конвертации между ними.Но я бы не хотел переходить непосредственно от EF к OData.

ПРИМЕЧАНИЕ. Я все еще хочу использовать EF в качестве ORM.Прокатить мой собственный ORM на самом деле не решение ...

Answer 1

Если вы используете свои собственные классы вместо классов, сгенерированных непосредственно EF, вы также измените предоставление для Служб данных WCF. Это означает, что вы больше не будете передавать контекст EF в качестве универсального параметра в DataService базовый класс. Это будет нормально, если у вас есть службы только для чтения, но если вы ожидаете каких-либо изменений данных от клиентов, у вас будет много работы.

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

Службы данных - это технология быстрого создания служб, предоставляющих ваши данные. Они связаны с их контекстом, и ответственность за обеспечение абстракции лежит на контексте. Если вы хотите быстро и легко предоставлять услуги, вы зависите от функций, поддерживаемых EF mapping. Вы можете сделать некоторые абстракции в EDMX, вы можете делать проекции (DefiningQuery, QueryView) и т. Д., Но все эти функции имеют некоторые ограничения (например, проекции доступны только для чтения, если вы не используете хранимые процедуры для изменений).

Услуги передачи данных не совпадают с предоставлением подключения к базе данных. Есть одно очень большое различие - подключение к базе данных обеспечит только доступ и разрешения на выполнение, но не обеспечит безопасность данных. Службы данных WCF обеспечивают безопасность данных, поскольку вы можете создавать перехватчики, которые будут добавлять фильтры к запросам, чтобы получать только те данные, которые пользователь может просматривать, или проверять, разрешено ли ему изменять данные. Об этом вы можете сказать своему коллеге.

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

Answer 2

Самый простой подход:

НЕ ИЗДАТЬ ВАШИ СТОЛЫ;)

• Создать отдельную схему
• Добавить к этому просмотру
• Поместите эти представления в EF и опубликуйте их.

Представления отделены от таблиц и, таким образом, могут быть упрощены и подвергнуты рефакторингу отдельно.

Стандартный подход, также для отчетности.

Answer 3

У вас есть несколько других опций для вашего клиента OData. Взгляните на Simple.OData.Client, описанный в этой статье: http://www.codeproject.com/Articles/686240/reasons-to-consume-OData-feeds-using-Simple-ODa

И если вы знакомы с Simple.Data microORM, для него есть адаптер OData: https://github.com/simplefx/Simple.OData/wiki

UPDATE. Мои рекомендации касаются выбора клиента, в то время как ваш вопрос касается настройки серверной части. Тогда, конечно, они не то, что вы спрашиваете. Однако я оставлю свой ответ, чтобы вы знали о клиентских альтернативах.

Answer 4

Помимо достижения более детальной авторизации данных (на основе определенных значений полей и т. Д.), OData также позволяет вашим данным быть доступными через открытые стандарты, такие как JSON / Xml через Http, используя OAuth. Это очень полезно для веб / мобильных приложений. Теперь вы можете создать веб-сервис для представления ваших данных, но это будет гарантировать изменение каждый раз, когда вашему клиенту потребуется изменить требования к данным (например, дополнительные поля необходимы), тогда как OData позволяет это через запросы OData. В больших компаниях это также полезно для проектирования безопасности на уровне инфраструктуры, поскольку оно разрешает только текстовые (http) вызовы, которые можно проверять / проверять на наличие угроз безопасности через сетевые брандмауэры ».