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

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

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

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

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

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

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

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

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

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

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


entity-framework odata wcf-data-services
person Vaccano    schedule 19.08.2011    source источник

Ответы (4)


arrow_upward
3
arrow_downward

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

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

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

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

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

person Ladislav Mrnka    schedule 19.08.2011
comment
Мне нравится эта идея. Мои службы данных WCF доступны только для чтения. Поэтому я думаю, что добавление моего собственного уровня абстракции может сработать. - person Vaccano; 19.08.2011

arrow_upward
1
arrow_downward

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

НЕ ПУБЛИКУЙТЕ СВОИ ТАБЛИЦЫ ;)

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

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

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

person TomTom    schedule 19.08.2011

arrow_upward
0
arrow_downward

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

person Suneet Nangia    schedule 11.03.2014

arrow_upward
0
arrow_downward

У вас есть другие варианты для вашего клиента 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

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

person Vagif Abilov    schedule 11.03.2014