Работа с объектными объектами ADO.NET и веб-службами на основе Soap

Question

Я создаю традиционный веб-сервис ASP.NET - стиль, созданный с использованием asmx. Это довольно простой сервис. Я начал использовать новую платформу Ado.NET Entity Framework для своего уровня персистентности, и у меня возникают некоторые проблемы:

1) Мне не нравится WSDL, который генерируется автоматически - сложные типы были определены так:

   <s:complexType name="TestObject">
      <s:complexContent mixed="false">
         <s:extension base="tns:EntityObject"> ...

Итак, я создал свой собственный WSDL и использовал инструмент wsdl.exe для создания определения сервиса, который включает в себя новое определение типа, так что теперь WSDL выглядит, как мне кажется, более кроссплатформенным дизайном:

<xsd:complexType name="TestObject">
  <xsd:sequence>
    <xsd:element minOccurs="0" name="created" type="xsd:dateTime"/> ...

Теперь у меня есть ASPX, генерирующий хороший файл WSDL. Но сейчас я не уверен, где мне взять это. У меня есть два типа в основном одного и того же типа для TestObject: 1) это используется для сохранения сущности с помощью ADO.NET Entity Framework 2) и тот, который используется для определения данных по проводам.

Я бы хотел выяснить, как их объединить. Я немного нервничаю из-за изменения файла .cs, который автоматически генерируется платформой Ado.NEt Entity, так как кажется, что он может быть перезаписан.

Кто-нибудь с большим опытом работы с сущностью Ado.Net считает, что его стоит использовать? Мне нравится идея о том, как быстро я смог создать постоянство для своего уровня данных, но мне нужно очень индивидуально определить, как объект сущности передается по проводам, поэтому мне нужно изменить атрибуты, связанные с ним. свойства. Кроме того, в моей реализации сервиса я не очень хочу этого, конвертируя EntityFramework.TestObject в WSDLDefenition.TestObject.

Спасибо за любой вклад.

Answer 1

Вы сталкиваетесь с такой стеной, с которой сталкивались многие из нас, когда пытались использовать Entity Framework в архитектуре в стиле SOA.

Версия 1.0 Entity Framework не очень хорошо работает в описанном вами сценарии, поскольку вы попадаете в мир боли, пытаясь управлять контекстами объектов (и, вероятно, приходится их кэшировать).

Я бы рекомендовал внимательно прочитать следующую (1) статью , опубликованную командой EF о будущем Entity Framework. Это также дает возможность фиксировать и обсуждать некоторые из текущих недостатков.

Короче говоря, я не уверен, что Entity Framework - это именно то решение, которое вам нужно прямо сейчас, поскольку на данном этапе не существует «чистого» решения для обработки объектов EF по проводам (или за пределами границ служб).

Другие могут просить отличия ...

P.S. Вы правы, опасаясь ручного редактирования сгенерированного кода - любые обновления модели данных будут перезаписывать любые модификации (хотя вы можете расширять их, поскольку они находятся в частичном классе). Бесполезно, если вы хотите добавить атрибуты к свойствам.

(а) http://blogs.msdn.com/efdesign/archive/2008/11/20/n-tier-improvements-for-entity-framework.aspx

Answer 2

Спасибо. Это то, что я подозревал, но не хотел тратить целый день на исследования. Пока я собираюсь держать свои объекты отдельно, таким образом, я могу сохранить чистый WSDL, а затем на уровне доступа к данным я буду конвертировать между объектами на проводе и объектом ADO.NET фреймворк.

Вероятно, не самый здравый подход, но это поможет мне в демонстрации.

Спасибо за ссылку на статью, я думаю, что ключевым понятием, которое я пропустил, было Постоянное Невежество. Я работал над веб-сервисами Java, где вы можете определить POJO (простые старые объекты Java) и легко передавать их по проводам, а также сохранять в источнике данных ...

... и теперь я понимаю, почему вы предлагаете WCF из-за поддержки Постоянного Неведения.