Silverlight как интерфейс для бизнес-приложений - PullRequest
2 голосов
/ 28 ноября 2009

Мы разрабатываем новое коммерческое приложение на основе .NET, в котором серверная часть будет работать как служба на сервере Windows (необязательно Azure). Для этого мы рассматриваем возможность использования Silverlight в качестве only front-end / GUI для доступа к приложению - прежде всего потому, что это обеспечит легкий доступ с различных платформ клиентских ОС. Пользователи приложения (компании, лицензирующие его) сами будут запускать вспомогательный сервис - мы не будем продавать его как сервис - это будет «старомодное» термоусадочное приложение.

Считаете ли вы Silverlight достаточно зрелым для этого?

Вам известны какие-либо существующие коммерческие приложения, которые работают таким образом?

Какой-нибудь конкретный совет / вещи, на которые стоит обратить внимание при реализации чего-то подобного?

Ответы [ 2 ]

4 голосов
/ 28 ноября 2009

Да, Silverlight достаточно зрелый.

Я начал разрабатывать его в июле 2008 года и через восемь месяцев отправил первую версию развертываемой системы мониторинга телеметрии клиент / сервер для сельского хозяйства. Несмотря на некоторые икоты и слаборазвитые области (больше с 2.0, чем с 3.0), я обнаружил, что он намного лучше, чем Windows Forms, для разработки быстрого интерактивного пользовательского интерфейса клиента - и даже не начинаю сравнивать с обычными технологиями www. ..

Я настоятельно рекомендую его, особенно в сочетании с WCF Data Services или RIA Services для бизнес-приложений.

2 голосов
/ 02 декабря 2009

Я использовал Silverlight в качестве внешнего интерфейса для коммерческого приложения для медицинской промышленности. Никаких серьезных ловушек, просто убедитесь, что вы создаете потоки для выполнения трудоемкой работы, чтобы пользовательский интерфейс не зависал, и убедитесь, что у вас есть файл clientaccesspolicy.xml, если вы обращаетесь к веб-службам.

Две «бизнес» проблемы, решаемые в Silverlight 3, - это отсутствие обработки ошибок (частично разрешенных) и поддержки безопасности на основе сообщений. Решение этих проблем очень важно для Silverlight в его стремлении продать себя как готовую к бизнесу технологию. Мое мнение, что это достаточно хорошо.

В SL2 было два ограничения, которые препятствовали обработке ошибок. Во-первых, исключения сервера поступают в виде кода ответа 500, который плагины браузера не могут обработать. Во-вторых, в SL2 нет поддержки исключений. SL3 решает вторую проблему, добавляя классы ExceptionDetail и FaultException. Первая проблема все еще существует. Код ответа 500 запрещает Silverlight доступ к содержимому ответа, но в качестве обходного пути вы можете отправить обратно код ответа 200 вместо 500.

SL2 поддерживает только безопасность на основе браузера. Приложение, разработанное с использованием этой модели безопасности, может быть уязвимо для попытки мошенничества между доменами со стороны вредоносных приложений с доступом к кэшированным учетным данным браузера. Безопасность на основе сообщений решает эту проблему путем включения учетных данных в каждое сообщение.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...