Контракты WCF от структуры сущностей?

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

Это ответ Тима Маллалье в 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 теперь вы можете свернуть свои услуги по своему усмотрению и отправить их по проводам.

источник

2009-02-25 Weej

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

источник

2009-02-25 18:29:55

В конце концов я сделал именно это. Надеюсь, это не ошибка в долгосрочной перспективе. Недостаток, который я вижу до сих пор, заключается в том, что я закончил реализацию шаблона репозитория на стороне клиента, а не на стороне модели. Я не доволен этим и, вероятно, придется реорганизовать позже. – Weej

Опасность ADO.NET Data Services заключается в том, что выполнить DDD-подход может быть довольно сложно. Вы должны рассматривать службы данных ADO.NET так же, как: услуги передачи данных. Если вам нужен более сильный набор сервисов модели, вам нужно создать это отдельно. – 2009-03-24 00:45:20

Даже с последней версией ADO .NET Data Services и EFCF 4.1 она по-прежнему сильно ограничивает. Например, ни один из операторов агрегации из LINQ не поддерживается, в том числе 'Distinct()'. Если вам нужно что-то большее, чем функции CRUD, вы должны держаться подальше от Data Services. – Yuck

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

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

источник

2009-02-25 15:20:34

Я рассмотрел это, но ум боится, сколько работы это может понести. С его точки зрения, простой код выше, похоже, не размывает разделение проблем. Если я собираюсь принять EF, я не за пенни, за фунт? Другими словами, я уже покинул территорию POCO. Нет? – Weej

OK Джон, извините, я пропустил вашу мысль. Вы говорите, что возвращаемый объект имеет «другие вещи», кроме простых данных. Это не хорошо. Есть ли какой-либо хороший способ, с которым вы столкнулись, будет генерировать отчеты о контрактах DTO? – Weej

Часть меня хочет, чтобы MS предложила подмножество WCF, которое менее интероперабельно, но больше Data Entity, Linq и т. Д., Но тогда что-то подобное добавляет сцепление, которое я не уверен, является хорошей идеей ... –

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

источник

2009-02-25 18:25:32

Некоторой более подробно в ответ на комментарий:

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

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

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

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

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

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

источник

2009-02-26 02:16:10

Контракты WCF от структуры сущностей?

ответ

Смежные вопросы