Заранее извиняюсь, это длинный вопрос.
(TL; DR: есть ли у кого-нибудь совет по использованию EF с динамическими полями, открытыми с помощью WCF Data Services / OData)
У меня возникают некоторые концептуальные проблемы с WCF Data Services и EF, в частности, касающиеся предоставления некоторых данных как службы OData.
В основном моя проблема заключается в следующем. База данных, которую я раскрываю, позволяет пользователям динамически добавлять поля (определяемые пользователем поля) и использует систему, посредством которой эти поля добавляются непосредственно в базовые таблицы SQL. Кроме того, если вы хотите добавить данные в таблицы, вы не можете использовать прямой SQL, вы должны использовать API, который они предоставляют. (это SAP Business One, fwiw).
Я уже успешно построил систему, которая предоставляет различные объекты через XML и позволяет клиенту обновлять или добавлять новые сущности в SBO, отправляя сообщения XML, и хотя она хорошо работает, она не совсем подходит для мобильных приложений, так как она очень насыщена XML и точка входа - это устаревший веб-сервис asmx. Я хочу попробовать оживить его для мобильной разработки и использовать Odata с WCF или веб-API. (Я знаю, что могу перейти на службу WCF, разрешить обработку запросов в формате JSON и начать возвращать данные JSON, но похоже, что должен быть более ... собственный ... способ) em>
Первоначально я отказался от возможности использования EF для этого, потому что а) динамические поля и б) EF может быть только для чтения; добавление / обновление объектов должно быть перехвачено и направлено на сервер SBO DI Server. Тем не менее, я возвращаюсь к размышлениям об этом и ищу совет (отрицательный или иной!) О том, как подойти к делу.
Что я в основном хочу сделать, так это это
Выставляйте базовые таблицы из SBO (которые не меняются, кроме случаев, когда они сами выпускают патч) как EF Entities, со всеми обычными качествами связи. На самом деле я не буду напрямую открывать таблицы, я буду использовать набор фильтрованных представлений SQL в качестве источников данных, поскольку это связано с различными другими действиями, которые мы делаем, чтобы разрешить доступ только определенных данных к третьим сторонам.
Предоставьте любые UDF, добавленные конкретным пользователем, как некую подколлекцию EAV для каждой сущности.
Перехватывайте любые запросы на ДОБАВЛЕНИЕ или ОБНОВЛЕНИЕ объекта и направляйте их через существующий механизм, который у меня есть для взаимодействия со службами импорта данных SAP.
Полагаю, мой главный вопрос заключается в следующем; Предположим, я реализую объект EF, представляющий заказ на продажу, который включает коллекцию заголовков и деталей. К каждому из этих классов я прикрепляю набор пользовательских полей и значений типа EAV. Сколько работы требуется, чтобы позволить системе фильтрации OData работать непосредственно с коллекцией EAV (например, чтобы клиент мог запросить Service / Orders / $ filter = SomeUdfField eq SomeValue, где этот запрос должен быть передан в коллекцию EAV объекта заголовка Order)
Или возможно, например, сгенерировать модель EF из каких-то метаданных на лету (я не возражаю, как - создание кода или библиотека построения модели), что означало бы, что я мог бы просто раскрыть каждую сущность, включая динамические поля, как подходящую модель EF? Заранее большое спасибо, если вы дочитали до этого места :)