Как я могу поделиться контрактами Linq to Entities между WCF и Silverlight?

Question

0 голосов вниз звезда 1

Я хочу иметь возможность поделиться своими контрактами на данные (классы, сгенерированные в конструкторе linq to entity, украшены атрибутом [DataContract].

Я пытаюсь использовать архитектуру, как описано здесь: http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2 и пытаюсь ссылаться на мои интерфейсы в моем проекте silverlight, используя метод «Добавить как ссылку», как описано здесь: http://www.netfxharmonics.com/2008/12/Reusing-NET-Assemblies-in-Silverlight

Проблема, с которой я столкнулся, - это ссылка на мой сервисный интерфейс в проекте Silverlight.

Мое решение имеет следующие проекты:

ORM - содержит модель edmx Linq to Entities (пространство имен: company.client.Service) - классы в ней украшены атрибутом DataContract и т. Д.

ServiceInterface - содержит интерфейсы (пространство имен company.client.Service) и ссылку на ORM для возвращаемых классов (Customer и т. Д.)

Служба - содержит реализацию интерфейсов службы (пространство имен company.client.Service) и ссылается на ServiceInterface и ORM для классов.

ServiceHost - содержит только файлы .svc, как рекомендовано в http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight-2

WebSLHost - хост для приложения silverlight

Gui - графический интерфейс Silverlight.

Я хочу, чтобы все проекты были стандартными сборками .net, за исключением, конечно, графического интерфейса silverlight.

Когда я пытаюсь добавить ссылку на мои файлы интерфейса службы (как показано в http://www.netfxharmonics.com/2008/12/Reusing-NET-Assemblies-in-Silverlight), выдается ошибка компиляции, в которой говорится, что он не может найти ORM и не может идентифицировать типы моих сущностей.

Я хочу иметь возможность поделиться данными, сгенерированными генератором linq для сущностей, с моим сервисом и клиентом silverlight, поэтому, если у кого-то есть какие-либо идеи, я буду признателен им.

Answer 1

То, что вы пытаетесь, будет работать только с «полным» .NET до «полного» .NET (или, по крайней мере, с соответствующим); и даже тогда это нарушает правила SOA ...

Вся идея контракта на данные заключается в том, что вы разделяете форму данных, но не реализацию. Это означает, что не имеет значения, что Silverlight не знает об EDMX или о некоторых более необычных разновидностях атрибутов DataContract (таких как обратные вызовы) - данные по-прежнему не повреждены.

Используя мексиканскую версию классов, вы по-прежнему будете иметь то же самое важное поведение данных - это предполагаемый вариант использования WCF с Silverlight. Так что просто используйте сервисную ссылку. В качестве альтернативы вам понадобится класс DTO, который находится между EDMX и WCF; до тех пор, пока DTO использует только атрибуты WCF (но не EDMX), все будет в порядке, но, очевидно, это требует огромных затрат на обслуживание. Я лично сомневаюсь, что оно того стоит в большинстве простых сценариев.

Answer 2

К сожалению, классы LINQ to Entities предоставляют некоторые возможности реализации в своих контрактах на данные. Они действительно сделали бы лучше, чтобы классы вообще не были контрактами на данные.

Как уже было сказано, просто создайте свои собственные классы контракта данных (DTO), которые соответствуют форме данных, которые будут возвращены. Вернуть отдельные экземпляры этих классов или список из них.

Я рекомендую не использовать DataSet, DataTable или что-либо еще для конкретной платформы. Причиной этого было то, что он не взаимодействовал с другими платформами, такими как Java. Однако я встречал ситуации, когда он не взаимодействует должным образом в .NET - между различными версиями .NET, и я подозреваю, что между полным .NET и Silverlight. Используйте DTO, как указано выше.

Answer 3

Я по-прежнему считаю, что лучше всего НЕ пытаться передавать классы linq-to-entity из компонента WCF вашему клиенту. Вместо этого создайте простые классы DataContract, которые просто содержат данные (только свойства). Заполните это на стороне WCF, отправьте через, а затем в вашем клиенте используйте данные, чтобы воссоздать правильный объект, который вы можете использовать с linq.

Имеет смысл?

Answer 4

Я вижу два возможных решения для этого.

1. Изменить сгенерированные классы linq-to-entity, окружив их директивами препроцессора не-silverlight строками

   если! SILVERLIGHT

   // Не Silverlight код

   ENDIF

2. Другой альтернативой является преобразование вашей сборки .NET в Silverlight-совместимую, как описано в этой статье: Преобразование сборок .NET в сборки Silverlight

Answer 5

Я пытаюсь сделать то же самое и только что опубликовал на форумах Silverlight.net.

Если нет пути, то какой ужасный недосмотр со стороны MS! Сущности - это будущее, в будущем в Linq to SQL не так много улучшений. Неужели так редко хочется использовать Silverlight + WCF + Entity Framework? Вы либо застряли с отдельными сущностями в каждом пространстве имен прокси-сервера службы (это упущение не работает в реальном приложении Silverlight), либо дублируете схемы и выполняете перевод между вашими схемами клиентов и схемами сущностей, что лишает красоту простота Entity Framework.

Answer 6

Из того, что было сказано здесь, и из того, что я читал в другом месте, кажется, что контракты на данные EDM просто не могут быть переданы Silverlight так, как мне бы хотелось.

Тем не менее, похоже, что можно поделиться linq to sql datacontracts с помощью Silverlight. Не совсем то, что я хотел, но кое-что, что я мог бы рассмотреть. Я только начинаю с WCF и silverlight и пока не решила, какой из моих вариантов самый лучший.