Як архітектуру корпоративних настільних додатків для Windows 8

Я думаю, що я розумію очікування розвитку програм для споживачів для Windows 8. Створіть новий інтерфейс на основі метро на WinRT, розгорніть його до свого клієнта через Marketplace, і кожен виграє. Здається, досить просто. На жаль, я не в цій справі.

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

Схоже, WPF та Silverlight мають сумнівні ф'ючерси на даний момент, тому продовжувати інвестувати в них трохи побоюється. Але інтерфейс Metro не здається підходящим для корпоративних програм, а API WinRT досить обмежує щодо "типових" речей, які потрібно робити корпоративним програмам.

Як я повинен будувати свої програми на базі 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, і навіть форми winform з цього питання.

З іншого боку, ви повинні погодитися, що для довгострокового проекту ви ніколи не будете мати найновішу, найприємнішу технологію.

Насправді питання, які ви повинні задати собі щодо вибору технології, це:

• Чи достатньо комфортна моя команда з цією технологією, щоб бути продуктивною?
• Чи моя команда із задоволенням використовує цю технологію?
• Чи можу я набрати людей за цією технологією?

Ось поєднання відповідей на ці запитання повинно спричинити ваш вибір, а не тенденції, сформовані переважно з маркетингових причин.

Щоб дізнатися більше про цю тематику технології, що постійно змінюється, слід прочитати "Пожежа та рух" Джоела Спольського :

Компанії, які спотикаються, - це ті, хто витрачає занадто багато часу на читання чайних листків, щоб визначити майбутній напрямок Microsoft. Люди турбуються про .NET і вирішують переписати всю свою архітектуру для .NET, тому що вони думають, що повинні. Microsoft стріляє на вас, і це просто прикриває вогонь, щоб вони могли рухатися вперед, а ви не можете, тому що так грається гра, Bubby. Ви збираєтесь підтримувати Граду? Мило? RDF? Ви підтримуєте це через те, що ваші клієнти цього потребують, або через те, що хтось стріляє у вас, і ви відчуваєте, що вам доведеться реагувати? Команди з продажу великих компаній розуміють прикриття вогню.

І це було написано майже десять років тому.

Архітектура та технології

Архітектура та технології - це дві окремі речі:

• Ви можете робити MVC з winforms .
• Ви можете робити MVVM за допомогою WPF / Silverlight .
• Ви можете робити MVC за допомогою ASP.NET .
• Ви можете робити все, що завгодно, включаючи MVC та MVVM, з WINRT, наскільки нам відомо .
• Ви можете працювати з F # . Чому ні ? Є домени, де це мало б сенс.
• Ви можете змішати їх усіх, мати різні точки входу до загальної системи, а потім знущатися, оскільки це стає занадто складним і т.д.

Ви можете користуватися послугами, ресурсами, сторонніми контролями, ORM тощо з усіма цими технологіями, а може, а може і ні, з наступними.

Ви можете перекручувати та згинати MVC багатьма способами за допомогою усіх цих технологій: прив'язування чи ні? код за переглядом чи ні? Контролер чи ні? ViewModel кожного разу або лише за потреби? Існує так багато способів реалізувати модель дизайну, навіть в рамках однієї конкретної технології.

Це було б нереально змусити вас вступити в один з них без попередніх знань про ваш проект та команду. Це базувалося б лише на особистих вподобаннях, і в результаті "мої технології кращі за ваші" виявляться.

Єдине, що можна чесно та об'єктивно запропонувати, - це використовувати найкращі практики, які можна застосувати, щоб створити архітектуру, яка витримає випробування часом, а може, справді, можливо, буде портативною або повторно використана хоча б у частинах із майбутнім невідомою технологією . А оновлення / портативність навіть не повинні бути головною метою вашої архітектури.

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

MVC (а це молодший брат MVVM) дедалі більше виявлявся основою для надійної архітектури з 1979 року на аренах мов OOP і за її межами. Але вибір того, яку саме технологію слід використовувати в проекті, що триває 10 років, повинен залишатися вашим рішенням.

Одне, на що я звернуся у своїй книзі про MVVM, - це використання шаблону для створення основного додатка для багаторазового використання. Вам слід створити власний інтерфейс користувача для різних платформ, на які ви орієнтуєтесь (будь то веб, Silverlight, телефон, WPF або WinRT). Але здебільшого ви можете інкапсулювати логіку, що керує інтерфейсом користувача за ViewModel.

Будь-які сервіси, до яких ви отримуєте доступ, повинні бути загорнуті за інтерфейс (модель фасаду), який є більш-менш портативним між платформами. Інтерфейс повинен відображатись на API вашого клієнта на передній панелі та перекладати на API обгорнутої служби на звороті.

Ця стратегія допомагає створити міцну основну основу, яка вимагає лише нового інтерфейсу, який повинен бути шарувати поверх неї. Подумайте про це як про вашу модель подання, що це м'язи, ваші служби складають кістяк (і органи). WPF / Silverlight / WinRT утворюють шкіру.

Насправді, одна річ, яку я зазначаю дуже рано у своїй книзі, - це те, що MVVM не такий новий, як здається. У дельфіна Малталка була схожа картина, яку вони називали MMVC (два M були прикладними і доменними моделями). ViewModel, який ми використовуємо сьогодні, - це лише комбінація прикладної моделі та контролера від MMVC. Насправді багато розробників виявляють, що іноді розділяти ViewModel на два компоненти має сенс (контролер, який використовується для навігації та оркестрування декількох віртуальних машин, щоб ВМ залишався невідомим про інші компоненти).

Ви кажете, що XAML є солідним, але тоді ви кажете, що WPF має сумнівне майбутнє. Якщо я щось не пропускаю, WPF використовує XAML, і я не бачу, щоб вони ніколи не розлучалися. Чи є якісь новини, які мені не вистачає про WPF, можливо, використання якоїсь іншої базової технології, або про Microsoft, навіть можливо, розглядаю можливість побудувати ще один новий спосіб побудови інтерфейсів? За винятком цього, я сумніваюся, що WPF їде куди завгодно, але це було б не вперше, коли MS застаріло навантаження на човні нашого коду ...

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

Думаю, що ви не повинні занадто зосереджуватись на деталях реалізації ваших заявок. Якщо ви подивитесь на більшу картину, ви можете виокремити свої залежність від технології. Завдяки ізолятину залежність, наприклад, від xaml / wpf / silverlight, ви гарантуєте, що зможете замінити компонент / технологію ui на технологію наступного покоління, а отже, гарантуйте наступність навіть через 20 років. Це також допоможе роз’єднати компоненти системи та тим самим вплинути на необхідність проведення такої заміни. (У цьому я роблю припущення, що для забезпечення безперервності добре попрацювати з рішенням, щоб перейти на платформу наступного покоління)

Інший спосіб забезпечити ізоляцію від цих технологічних залежностей - це уможливлення віртуалізації. Якщо ви зробите свої програми таким чином, що зможете запускати їх у vm, ви зможете це зробити через 20 років!