Как создать корпоративные настольные приложения для Windows 8

Я думаю, что я понимаю ожидания разработки потребительских приложений для Windows 8. Создайте новый пользовательский интерфейс на основе Metro поверх WinRT, разверните его для своих клиентов через Marketplace, и все выиграют. Кажется достаточно простым. К сожалению, я не в этом деле.

Я работаю над внутренними бизнес-приложениями для крупного предприятия. В настоящее время мы используем технологии .NET, такие как WPF и Silverlight, для создания многофункциональных интерфейсов, которые могут быть легко развернуты для наших пользователей через Интернет или ClickOnce. Приложения могут поддерживать WinXP и Win7 без особой головной боли, и наши разработчики могут использовать XAML - очень надежную технологию пользовательского интерфейса.

Похоже, что на данный момент у WPF и Silverlight есть сомнительное будущее, поэтому немного тревожно продолжать инвестировать в них. Но пользовательский интерфейс Metro не кажется подходящим для корпоративных приложений, а WinRT API весьма ограничен в отношении «типичных» вещей, которые должны делать корпоративные приложения.

Как я должен проектировать свои приложения на основе XAML, которые в настоящее время развертываются в WinXP и Win7, чтобы они могли поддерживаться и развиваться в Win8?

Для целей этого вопроса предположим, что функции, предоставляемые HTML5 поверх ASP.NET, не подходят для приложений, которые я ищу для создания. Я понимаю, что могу использовать HTML5 для некоторых приложений, но я пытаюсь понять, что мне следует делать, когда этого недостаточно.

Редактировать # 1: Это в ответ на комментарий @Emmad Kareem. Я согласен, что Silverlight / WPF жизнеспособны в краткосрочной перспективе (2-5 лет). Однако приложения, которые мы производим, имеют потенциально очень долгий срок службы (10-20+ лет). Таким образом, выживаемость в долгосрочной перспективе для данной технологии является проблемой для нас. Кроме того, у нас есть некоторые опасения, что будет все труднее найти разработчиков, заинтересованных в разработке Silverlight / WPF, если сообщество считает эти технологии «мертвыми». Я просто хочу понять свои варианты и принять решение с открытыми глазами.

Как я научился перестать беспокоиться и любить MS-стек

Вы все еще можете запускать приложения VB6 на Windows 8 . Ретро-совместимость хорошо или плохо всегда была тенденцией в экосистеме MS. Вам не нужно беспокоиться о выживании таких технологий, как WPF / Silveright, и даже о том, как выиграть.

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

На самом деле вы должны задать себе вопросы о выборе технологии:

• Достаточно ли удобна моя команда с этой технологией, чтобы быть продуктивной?
• Моя команда счастлива использовать эту технологию?
• Могу ли я набирать людей для этой технологии?

Вот комбинация ответов на эти вопросы, которые должны привести ваш выбор, а не тенденции, выкованные в основном по маркетинговым причинам.

Чтобы узнать больше об этой теме постоянно меняющихся технологий, вы должны прочитать «Огонь и движение» Джоэла Спольски :

Компании, которые спотыкаются, - те, кто тратит слишком много времени на чтение заварки, чтобы выяснить будущее направление Microsoft. Люди беспокоятся о .NET и решают переписать всю свою архитектуру для .NET, потому что думают, что должны. Microsoft стреляет в тебя, и это просто прикрывает огонь, чтобы они могли двигаться вперед, а ты не можешь, потому что именно так играется, Бэбби. Собираетесь ли вы поддержать Hailstorm? МЫЛО? RDF? Поддерживаете ли вы это, потому что это нужно вашим клиентам или потому, что кто-то стреляет в вас, и вы чувствуете, что должны ответить? Команды продаж крупных компаний понимают прикрытие огня.

И это было написано почти десять лет назад.

Архитектура и Технологии

Архитектура и технологии - это две разные вещи и выбор:

• Вы можете сделать MVC с winforms .
• Вы можете сделать MVVM с WPF / Silverlight .
• Вы можете сделать MVC с ASP.NET .
• Насколько нам известно, вы можете делать все, что захотите, включая MVC и MVVM, с WINRT .
• Вы можете работать с F # . Почему нет ? Есть домены, где это имеет смысл.
• Вы можете смешивать их все, иметь разные точки входа в общую систему, а затем подвергаться насмешкам, потому что это становится слишком сложным , и т. Д.

Вы можете использовать сервисы, ресурсы, сторонние элементы управления, ORM и т. Д. Со всеми этими технологиями, а может быть, а может и нет, со следующими.

Вы можете крутить и сгибать MVC разными способами со всеми этими технологиями: связывание или нет? код за взглядом или нет? Контроллер или нет? ViewModel каждый раз или только при необходимости? Существует множество способов реализации шаблона проектирования, даже в рамках одной конкретной технологии.

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

Единственное, что можно честно и объективно предложить, - это использовать лучшие практики, которые вы можете применить, для создания архитектуры, которая выдержит испытание временем, и, возможно, действительно, может быть, будет переносимой или будет повторно использоваться, по крайней мере, в частях с неизвестной будущей технологией. , И эта возможность обновления / переносимости даже не должна быть главной целью вашей архитектуры.

Основная цель вашей архитектуры и выбранных технологий - доставить продукт вашему боссу / заказчику, который соответствует его реалистичным требованиям.

MVC (и его младший брат MVVM) с 1979 года все больше и больше становятся основой для надежной архитектуры в области языков ООП и за ее пределами. Но выбор конкретной технологии, которая будет использоваться в 10-летнем проекте, должен оставаться вашим решением.

В моей книге о MVVM я расскажу о том, как использовать шаблон для создания многоразового основного приложения. Вы должны создать собственный пользовательский интерфейс для различных платформ, на которые вы нацелены (будь то веб, silverlight, телефон, WPF или WinRT). Но по большей части вы можете инкапсулировать логику, управляющую этим пользовательским интерфейсом за ViewModel.

Любые сервисы, к которым вы получаете доступ, должны быть заключены в интерфейс (шаблон Facade), который более или менее переносим между платформами. Интерфейс должен отображаться на вашем клиентском API на передней панели и переводиться на API упакованной службы на задней панели.

Эта стратегия помогает вам создать прочную базовую структуру, для которой требуется только наложение нового пользовательского интерфейса поверх него. Думайте об этом как о вашей модели представления, которая является мышцами, а ваши службы составляют каркас (и органы). WPF / Silverlight / WinRT образуют скин.

На самом деле, одна вещь, на которую я очень рано обращаю внимание в своей книге, это то, что MVVM не так нов, как кажется. У Dolphin Smalltalk была похожая модель, которую они назвали MMVC (две М были Модель приложения и Модель предметной области). ViewModel, который мы используем сегодня, является просто комбинацией модели приложения и контроллера из MMVC. Фактически многие разработчики находят, что иногда разделение ViewModel на два компонента имеет смысл (контроллер, используемый для навигации и организации нескольких виртуальных машин, так что виртуальная машина может оставаться в блаженном неведении о других компонентах).

Вы говорите, что XAML надежен, но потом говорите, что у WPF сомнительное будущее. Если я что-то не упустил, WPF использует XAML, и я не вижу, чтобы эти две части были разделены. Есть ли какие-то новости, которые я упускаю из-за того, что WPF, возможно, использует какую-то другую базовую технологию, или о том, что Microsoft даже рассматривает возможность создания еще одного нового способа создания пользовательских интерфейсов? Помимо этого, я сомневаюсь, что WPF куда-то пойдет, но это не первый раз, когда MS устарела из-за загрузки нашего кода ...

Если вам нужно приложение с богатым пользовательским интерфейсом, а HTML5 его не обрежет, а ваша организация привержена ОС Windows, я думаю, что WPF - лучший выбор, так как он самый последний / лучший на данный момент, конечно же, по сравнению с winforms ...

Я полагаю, что вам не следует уделять слишком много внимания деталям реализации ваших приложений. Если вы посмотрите на более широкую картину, вы можете выделить свои технологические зависимости. Выделив зависимость, например, от xaml / wpf / silverlight, вы гарантируете, что можете заменить компонент / технологию пользовательского интерфейса технологией следующего поколения и, следовательно, гарантируете непрерывность даже через 20 лет. Это также поможет отделить компоненты вашей системы и тем самым повлиять на необходимость такой замены. (В этом я предполагаю, что для обеспечения преемственности можно возиться с решением, позволяющим запустить его на платформе следующего поколения).

Другой способ обеспечить изоляцию от этих технологических зависимостей - включить виртуализацию. Если вы создадите свои приложения таким образом, что сможете запускать их в виртуальной машине, вы сможете сделать это через 20 лет!