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

Question

У меня много тупиков в этом вопросе. Предположительно, .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();
        }
    }
}

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

Answer 4

Вы можете пойти простым путем и использовать ADO.NET Data Services .