Повторное использование на стороне сервера класса silverlight, использующего доменные службы .Net RIA - PullRequest
2 голосов
/ 01 июля 2010

В настоящее время у меня есть работающее приложение Silverlight, которое использует .Net RIA Services.

Это структура:

на стороне клиента

  • Application.Client.UI.dll (Xamls и базовый интерфейс)
  • Application.Client.BL.dll (содержит ссылку на RIA и большую часть бизнес-логики)

Серверный

  • Application.Server.Data.dll (dll на стороне сервера, который содержит Entity-модель и созданную им службу домена)
  • Application.Server.Web.dll (только хост-контейнер ASP.net, который ссылается на Application.Server.Data.dll)

Я разместил большую часть бизнес-логики на стороне клиента (Application.Client.BL.dll) для лучшего взаимодействия с пользователем (быстрые реакции) и для освобождения ресурсов сервера. Теперь моя задача - повторно использовать эту dll на стороне клиента, включая возможности доступа к данным RIA, в службе Windows на стороне сервера. Мне интересно, это вообще возможно? Является ли Application.Client.BL.dll по-прежнему способным использовать существующую службу RIA, или для этого требуется, чтобы среда выполнения Silverlight идентифицировала / обнаружила свою цель службы, и, следовательно, больше не будет работать.

Любопытно за ваши ответы

Ответы [ 3 ]

0 голосов
/ 05 января 2011

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


Если существуют какие-либо проблемы со ссылкой на сборку Silverlight, рассмотрите возможность создания двух проектов следующим образом:

Project # 1 будет вашей библиотекой Silverlight и должен содержать все исходные файлы, которые вы хотите использовать на клиенте.

Project # 2 будет вашей службой Windows. Вместо непосредственного включения исходных файлов используйте «Добавить существующий элемент», найдите исходный исходный файл в проекте № 1, затем (и это magic ) нажмите на кнопку «Добавить», чтобы выбрать вместо этого: выберите «Добавить как ссылку».

screenshot

Включая исходный файл в качестве ссылки, вы сохраняете возможность хранить исходный код в одном месте, но добавляете возможность компилировать ваш код для нескольких сред. Пока код опирается на сборки, доступные как в платформе Silverlight, так и в полной платформе .NET, то вы - деньги.


Теперь, независимо от того, выбираете ли вы мультипроектный подход, знайте, что у классов контекста домена есть дополнительные конструкторы, которые позволяют вам указывать контекстную информацию, такую ​​как URL, для соответствующей доменной службы. Я использую следующий код в одном приложении для создания контекста домена для службы домена, которая предоставляет данные о персонале:

var context = new PersonnelDomainContext(
    new Uri(ConfigurationManager.AppSettings["PersonnelServiceUrl"]))

В этом случае URL выглядит примерно так:

http://website-url/Services/Hyphenated-Namespace-PersonnelDomainService.svc

Конечно, при написании службы Windows ничто не мешает вам напрямую ссылаться на серверную службу (не контекстную) сборку. Имея доменную службу в руках, вы можете создать экземпляр службы без дополнительной настройки и дополнительной сетевой нагрузки XML. У этого подхода есть свои недостатки, такие как утрата централизованного управления конфигурацией (например, строк подключения), но в зависимости от обстоятельств вы можете найти, что компромиссы того стоят.

Удачного кодирования!

0 голосов
/ 05 мая 2011

Рассматривали ли вы возможность использования fork-reuse ? Взгляните на:

http://sharednow.blogspot.com/2011/05/its-not-just-reuse.html

0 голосов
/ 06 июля 2010

Вы действительно не должны ставить какую-либо бизнес-логику на клиента, парни в области безопасности и / или архитектуры будут ненавидеть вас за это ;-) Кроме того, вы не можете использовать сборки Silverlight в проектах ASP.Net или Desktop и наоборот. Если память работает правильно, Silverlight использует совершенно другой CLR.

...