Подходит ли Silverlight для большого LOB-приложения?

Question

Итак, я на стадии проверки концепции для довольно большого LOB-приложения. Приложение будет развернуто на многих компьютерах (более 200) во многих организациях. Он будет содержать множество экранов типа CRUD (около 100), а также некоторые довольно сложные процессы, такие как генерация счетов и интеграция с бухгалтерской книгой. Он также будет содержать много отчетов.

Я уже сделал много домашней работы и в значительной степени остановился на технологическом стеке:

• PRISM
• CSLA
• NHibernate

Все, что не хватает, это уровень представления, и поэтому мой вопрос таков:

Является ли Silverlight 3 подходящей технологией для создания такого большого приложения?

Изначально я был обеспокоен отсутствием истории отчетов для Silverlight, но теперь есть коммерческий инструмент отчетности , позволяющий решить проблему. Так что теперь я задаюсь вопросом о размере моего приложения и о том, на что будет похожа производительность, когда они попытаются загрузить его в свой браузер. С более чем 100 "экранами" и целой кучей отчетов это не будет легким способом.

Является ли Silverlight 3 разумным вариантом или я должен вместо этого смотреть на WPF? Основной причиной SL3 была проблема развертывания на многих настольных компьютерах во многих организациях.

Answer 1

Я бы предложил Silverlight 3.0 для LOB-приложения, если вашему приложению требуется следующее.

• Интерфейс расширенного клиента
• автономные / иногда связанные сценарии
• Возможность имитации модели веб-развертывания

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

С другой стороны, я бы пересмотрел использование Silverlight 3.0, если выполнено любое из следующих действий.

• Вам необходимо взаимодействовать с USB-устройствами, такими как сканеры.
• Вам необходимо взаимодействовать с другими приложениями на клиенте.

Если вам гарантирован стандартный клиент, возможно, вы захотите изучить приложение Windows «Click-Once». Он преодолевает вышеуказанные ограничения, не связан «песочницей», и вы все еще можете использовать модель веб-развертывания.

Answer 2

Мы делаем приложение SL3 для 5000+ пользователей, но с меньшим количеством экранов (30+), и мы считаем, что это возможно. Мы также работаем с приложением на 4 экрана для такого же количества пользователей. Если вас беспокоит производительность загрузки, вы можете сделать две вещи:

1. Перепрессуйте XAP чем-нибудь хорошим, например, 7zip - это дает намного лучшие результаты по сравнению с собственным компрессором.
2. Разделение приложения на отдельные приложения SL3 и загрузка соответствующих деталей по запросу.

Answer 3

Чтобы уменьшить исходное приложение, вы также можете загружать модули XAML по требованию (даже если это усложняет ситуацию). Обычно пользователи не будут возражать против времени загрузки, если приложение хорошо реагирует, когда вы работаете с ним (и это должно хорошо соответствовать SL3). Возможно, другой альтернативой будет .net с ajax и SL3 для пользовательского интерфейса, где это абсолютно необходимо.

Это довольно свежая технология для создания такого большого приложения, но оно должно быть выполнимым. Если он становится слишком тяжелым, его можно решить, создав различные модули. Помните также, что рабочие задачи, которые логически выполняются вместе, хранятся в одних и тех же модулях.

Answer 4

Примите также во внимание, что среда выполнения Silverlight доступна только для Windows и Mac, поэтому забудьте о Silverlight, если вы хотите, чтобы ваше приложение можно было использовать из браузера, скажем, в коробке Linux.

(Да, я знаю, что есть Лунный свет . Но я бы не стал класть яйца в эту корзину, если по какой-то неясной причине Microsoft решит принять участие в этом проекте.)