Контракты WCF от платформы сущностей?

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

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

Типы сущностей, которые генерируются в Entity Framework, по умолчанию представляют собой Контракты данных. Если бы мне пришлось создать простую модель в Entity Designer, например: Тип Entity Cart по умолчанию является 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, теперь вы можете свертывать свои службы по своему усмотрению и отправлять их по проводке.

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

Более подробная информация в ответ на комментарии:

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

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

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

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

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

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