Я узнал о IQueryable и ленивом загрузке/отложенном выполнении запросов.
Можно ли выявить эту функциональность над WCF? Я хотел бы предоставить службу LINQ-to-SQL, которая возвращает IQueryable, после чего я могу выполнить дополнительные запросы на клиенте и, наконец, выполнить с использованием .ToList(). В этом контексте применим формат OData?
Если возможно, что это за термин для этой техники и какие хорошие учебники я могу последовать? Спасибо.
Вы должны проверить службы данных WCF, которые позволят вам определить запрос Linq на клиенте. Служба данных WCF, вероятно, является единственным решением для вашего требования.
IQueryable по-прежнему остается только интерфейсом, а функциональность зависит от типа реализации интерфейса. Вы не можете напрямую подвергать запросы Linq-To-Sql или Linq-To-Entities. Существует несколько причин, таких как короткие контексты жизни или сериализация, которые будут выполнять запрос, чтобы клиент получил список всех объектов вместо запроса.
Насколько я знаю, datacontext не является сериализуемым, что означает, что вы не можете передавать его с помощью WCF
Вы можете использовать http://interlinq.codeplex.com/, который позволяет отправлять запрос Linq по WCF.
Службы передачи данных WCF могут использоваться только с webHttpBinding, и не все запросы Linq могут быть выражены. Написание запросов при использовании службы данных WCF не так привлекательно - для этого нужны строковые выражения, например:
.AddQueryOption("$filter", "Id eq 100");
https://remotelinq.codeplex.com/ - еще один выбор. Но он работает в AppDomain для сканирования текущих сборок и их сериализации. Эта технология не подходит для WinRT, поскольку без доменов для приложения WinRT
Я боролся с одним и тем же вопросом и понял, что проблема с правильной формулировкой - проблема, которая решается.
IQueryable в основном служит для фильтрации запроса перед отправкой его на ваш вызов БД, поэтому вместо того, чтобы получать 1000 записей и фильтровать только 10, вы начинаете их с 10. Эта фильтрация относится к вашему уровню обслуживания, но если вы создаете API, я бы предположил, что вы сопоставили бы его с параметрами AND/OR в вашем URL-адресе.
HTTP:.//{хост}/{объект}/д имя = джон & возраст = 21
Итак, вы получите что-то вроде этого:
Filter:Column1=Value1 > http://{host}/{entity}q?column1=value1 > SELECT *
FROM Entity
WHERE Column1=Value1
MVC > WCF > DB
Вы можете найти очень хороший образец [здесь]
Наконец, поскольку ваша полезная нагрузка из WCF, скорее всего, будет JSON, вы можете (и должны) затем десериализовать их в своих моделях домена внутри коллекции. До тех пор, пока этот пункт не будет происходить, поэтому я бы порекомендовал некоторое кэширование WCF (и с его HTTP, это действительно просто). Вы все равно будете использовать LINQ на стороне WebApp, просто без предложения WHERE LINQ (если вы не хотите динамически создавать URL-адрес, выраженный выше?)
Для сложного запроса OR вы должны решить несколько запросов WCF (1 на "И" ), а затем объединить их вместе
Если возможно отправить IQuerable < > over WCF, это не очень хорошо, так как IQuerable < > может выставлять в базу данных такие вещи, как строка подключения. Некоторые из предыдущих комментариев кажутся многообещающими.