Контракты WCF от Entity Framework?

Я заходил в тупик по этому вопросу. Предположительно, .NET 3.5 SP1 поддерживает сущности ADO.NET Entity Framework в контрактах WCF. Но когда я ищу по нему основательную информацию, я не получаю много ответов. Я нашел этот фрагмент в ветке MSDN. У кого-нибудь есть опыт с этим? Что случилось с [DataContract]? Это все, что нужно? Почему об этом так мало материала?

Это ответ Тима Маллали из Microsoft.

Типы сущностей, которые создаются в Entity Framework, по умолчанию являются контрактами данных. Если бы мне пришлось создать простую модель в Entity Designer, как показано ниже: Тип сущности корзины по умолчанию является DataContract со всеми свойствами, аннотированными как члены данных. Затем мы можем использовать это в службе WCF следующим образом:

[ServiceContract]

public interface IService1

{
    [OperationContract]
    Cart[] AllCarts();
}



public class Service1 : IService1

{
    public Cart[] AllCarts() 

    {
        using (MSPetShop4Entities context = new MSPetShop4Entities())

        {
            var carts = from c in context.Carts select c;
            return carts.ToArray();
        }
    }
}

Поскольку Сущности - это Контракты данных, теперь вы можете развернуть свои услуги по своему усмотрению и отправлять их по сети.

Ответов (4)

Решение

Вы можете пойти простым путем и использовать службы данных ADO.NET .

Еще немного подробностей в ответ на комментарии:

Есть несколько проблем с классами, генерируемыми EF. Сейчас я рассматриваю пример AdventureWorks с SalesOrderHeader и SalesOrderDetail. Сущность SalesOrderDetail имеет свойства SalesOrderHeader и SalesOrderHeaderReference, оба помечены как DataMembers. Это похоже на ошибку, поскольку свойство SalesOrderHeader также помечено [XmlIgnore] и [SoapIgnore].

Также подумайте, хотите ли вы в первую очередь сериализовать ссылку обратно на родительский SalesOrderHeader. Кроме того, что именно нужно сериализовать? SOAP не поддерживает ссылки совместимым образом.

Наконец, базовые классы сущностей также являются контрактами данных. Тем не менее, они не имеют ничего общего с возвращаемыми вами данными - они являются чисто артефактом реализации.

Короче говоря, Microsoft облажалась с этим. Они этого не продумали.

Что касается способов создания классов DTO, я предлагаю изучить различные инструменты генерации кода, такие как CodeSmith. Вы можете написать код, чтобы сделать это самостоятельно; Я так и поступил на предыдущей должности. Хорошая вещь в создании DTO заключается в том, что вы также можете генерировать методы для преобразования в DTO и из него.

Что касается накладных расходов, накладные расходы на перемещение некоторых данных в памяти - ничто по сравнению с количеством времени, которое потребуется для отправки данных по сети!

Я рекомендую вам не возвращать Entities напрямую. К сожалению, Microsoft решила включить данные, относящиеся к реализации, как часть DataContract для сущностей. Это не будет взаимодействовать с другими платформами и может не взаимодействовать даже между версиями .NET.

Вместо этого я рекомендую вам следовать шаблону объекта передачи данных и просто возвращать классы POCO, которые являются копиями данных в сущностях, без какого-либо поведения. Вы можете вернуть список таких классов для представления таблицы и т. Д.

Принцип «совместного использования интерфейсов, а не типов» предполагает, что вы не владеете обоими концами провода и / или пишете общедоступную веб-службу. WCF можно использовать (и используется) в тех контекстах, где это определенно не так. Во многих многоуровневых корпоративных архитектурах есть уровень приложений на основе WCF, который, помимо прочего, упрощает балансировку нагрузки. В этих случаях общий тип вполне допустим и, по сути, желателен.