Сервисные операции

Иногда возможности запрашивать данные и выполнять простые обновления или создания недостаточно - вы можете захотеть реализовать некоторую бизнес-логику или создание сложных запросов, которые невозможны с помощью схемы URI. Data Services поддерживает это в очень простой форме с помощью Service Operations.

Они позволяют добавлять методы в службу, но с некоторыми ограничениями:

1. Вы можете использовать только базовые типы или типы сущностей (т. Е. Типы, уже представленные службой).
2. Параметры метода могут быть только простых типов, которые могут быть выражены как часть URL-адреса.
3. Datasvcutil не генерирует код для Service Operations, поэтому вам нужно добавить их в клиентские библиотеки самостоятельно.
4. Если вы возвращаете тип объекта, но вам нечего возвращать, то есть результат равен нулю, тогда вы получите 404 в качестве ответа HTTP.
5. Если вы вернете void, вы не сможете использовать контекст данных клиента для выполнения запроса, вам придется использовать WebRequest.

Примеры (хорошо, они упрощены, поэтому на самом деле не обязательно должны быть сервисными операциями):

[WebGet]
public Product GetProductByID(int productID)
{
    return this.CurrentDataSource.Products.First(p => p.ID == productID);
}

[WebGet]
public IEnumerable<Product> GetCancelledProducts(int productID)
{
    return this.CurrentDataSource.Products.Where(p.Cancelled);
}

Клиентская библиотека Silverlight

Запрос LINQ

Сначала кажется, что синтаксис linq нельзя использовать из вашего контекста, потому что все запросы асинхронны, а IEnumerable, очевидно, не имеет метода BeginExecute. Чтобы использовать синтаксис Linq, вам необходимо выполнить конечный запрос:

var query = (DataServiceQuery<Product>)myContext.Products.Where(p => p.SupplierID == 5);
query.BeginExecute(this.HandleQueryResults, query);

Обратите внимание, что запрос передается, это потому, что вам нужно использовать тот же экземпляр DataServiceQuery для вызова EndExecute, вы не можете просто использовать контекст.

Отслеживание изменений

Клиентская библиотека не отслеживает автоматически изменения полей в сгенерированных типах. Чтобы это работало, вы должны реализовать INotifyPropertyChanged в своих частичных типах.

Пример:

public partial class Product : INotifyPropertyChanged {

    public event PropertyChangedEventHandler PropertyChanged;

    partial void OnProductIDChanged() { FirePropertyChanged("ProductID"); }
    partial void OnProductNameChanged() { FirePropertyChanged("ProductName"); }

    private void FirePropertyChanged(string property) { ... }
}

В версии 1.5 инструмент Data Services может генерировать это за вас, но в настоящее время это только в CTP: Введение в привязку данных в Silverlight 3 с 1,5 CTP2

Обновленные данные сервера

По умолчанию для контекста клиента Silverlight для параметра MergeOption задано значение AppendOnly. Это означает, что вы не увидите никаких изменений в объектах после того, как запросите их в первый раз, это форма кэширования и оптимизации производительности. Чтобы видеть обновления, вам нужно изменить MergeOption на OverwriteChanges, это обеспечит обновление объектов. Вы также можете отбросить свой контекст и воссоздать его.

myContext.MergeOption = MergeOption.OverwriteChanges

Междоменный доступ

Типы, сгенерированные Silverlight для ADO.NET Data Services 1, используют свой собственный сетевой стек, чтобы сделать доступными больше команд запросов, но, к сожалению, это означает, что междоменные политики не применяются, и вы не можете выполнять междоменные запросы. Чтобы обойти это, вы можете либо проксировать запросы, либо дождаться версии 1.5 (в настоящее время доступна CTP 2), которая поддерживает междоменный доступ в Silverlight 3.

Ссылки:

• Создание прокси-сервера службы данных ADO.NET
• Использование клиента Silverlight ADO.NET Data Services 1.5 CTP 2 в x-домене и в сценариях вне браузера

Работа с Linq to SQL

Вы можете использовать Linq to SQL в качестве контекста данных только для чтения для служб данных прямо из коробки:

public class MyService : DataService<MyLinqToSqlDataContext>

Однако для получения поддержки обновления / записи вам потребуется реализация IUpdateable для Linq to SQL. К счастью, у Эндрю Конрада есть для вас один в галерее кода MSDN:

Реализация IUpdateable служб данных ADO.Net для Linq to Sql

Отбросьте это как частичный класс для вашего контекста данных, и вы готовы как писать, так и читать. Обратите внимание, что у этой реализации есть несколько мелких проблем, подробно описанных на сайте, и что иногда использование Data Services с Entity Framework, как задумано, кажется немного более плавным.

Обновить проверки

При сохранении изменений вы увидите, что Linq to Sql генерирует предложение WHERE, которое проверяет существующие значения в полях, что не всегда то, что вам нужно. Это на самом деле совет Linq to Sql, а не специфический для Data Services, но это единственное место, где я использую Linq to Sql. Чтобы остановить это поведение, войдите в конструктор Linq to Sql и выберите поля, которые вы не хотите проверять. Измените свойство UpdateCheck на Never или OnlyWhenChanged.