Рамочная основа предприятия - UWP Vs. Web

Question

Широкий, широкий вопрос здесь ...

Предположим, вы создали инфраструктуру уровня предприятия с некоторым богатым клиентом в сфере .Net (Microsoft) с концом WCF. Теперь представьте, что технология пользовательского интерфейса корпоративной инфраструктуры устарела в пользу UWP.

Варианты замены переднего конца в основном: UWP, Web (HTML) или другая богатая клиентская технология.

Как вы относитесь к процессу принятия решений?

Я лично склоняюсь к богатому клиенту, где пользовательская база является доступной пользовательской базой. Я имею в виду, что ИТ-отдел пользователей с удовольствием устанавливает необходимую среду выполнения на машинах и т. Д. Обычно это не проблема с технологиями Microsoft, и это не будет проблемой примерно через 10 лет, когда организации будут развертывать Windows 10.

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

Я действительно был отключен веб-решениями, такими как ASP в прошлом, но я понимаю, что технология продвинулась вперед, и я понимаю, что Microsoft работает над ASP.Net v Next, которая действительно может быть хорошей?

Вопрос не столько в том, что вы бы выбрали? Но, Какие факторы вы бы взяли на учет, чтобы решить, какую платформу нужно делать для?

Answer 1

Я решил ответить на этот вопрос здесь, потому что у нас было гораздо больше времени для изучения и изучения различных вариантов. Первоначальный вопрос оказался немного фарфовым. Чистые UWP и Web - не единственные варианты. Также есть Xamarin Forms, который включает UWP, Android и iOS. В качестве личного предпочтения я склоняюсь к использованию Xamarin Forms в качестве клиента вместо любой другой платформы разработки, потому что он поддерживает три ОС из коробки: Windows 10, iOS и Android.

Я считаю, что ответ на вопрос: вы должны только разработать веб-приложение, если вам нужно. Ваша пользовательская база состоит из людей, которые в основном предпочитают браузер через приложения? Могут ли ваши потенциальные пользователи избежать загрузки приложения? Является ли ваше приложение очень простым, и вы хотите, чтобы люди могли погружаться очень быстро? Можете ли вы уйти без доступа к вещам, таким как камера, местоположение и push-уведомления? Если вы можете ответить «да» на эти вещи, я думаю, вам стоит пойти на HTML 5/JavaScript. Если, однако, ваша пользовательская база удобна в загрузке приложений, и вы считаете, что для вашего приложения потребуется более сложный интерфейс, чем большинство приложений для браузера, я бы рекомендовал посмотреть на Xamarin Forms в качестве предпочтительного варианта. До сих пор у нас был очень хороший успех с Xamarin Forms, а версия UWP нашего приложения Xamarin Forms оказалась так же хороша, как и наш первый удар в приложении UWP.

Примечание: Я должен предоставить веб-сборку (http://webassembly.org/) почетное упоминание здесь. Эта технология рассматривается во всех крупных технологических организациях, таких как Microsoft, Apple и Google. Однажды, это может сделать развертывание родных приложений в браузере великолепным снова.

Answer 2

Opnion на основе ответа здесь ...

В решении принять конкретную технологию для любого проекта лежит во многих факторах. Я могу привести две специальности для вашего конкретного сценария.

1 - Усыновление клиента. Клиентам это легко использовать/установить? Им нужно заплатить какую-то лицензию? Может ли он работать на всех платформах/устройствах, которые уже есть у клиента?

2 - Принятие на рынок. Легко для вас, коллеги, принять его? Трудно найти/нанять опытных/закаленных разработчиков? Нам нужно заплатить какую-то лицензию? Могу ли я надеяться, что это будет долгой технологией?

Ответ на ваш вопрос может быть HTML.

Не только это уже набирает обороты на рынке, но и многие годы могут изменить его, даже если сегодня кто-то (большой, как MS или Google) положил на стол новые (лучшие) вещи.

Также, если кто-то из MS marketing dep скажет на следующей неделе, то Universal Windows Platform или WinRT должны умереть, он плохо умеет (например, Silverlight). Поэтому я не принимаю какую-то новую технологию только потому, что какой-то большой игрок сказал мне сделать это.

Да Сеть прошла долгий путь действительно. В эти дни вы можете делать много удивительных вещей только с помощью JS + HTML + CSS. Кроме того, правильное использование/архитектура этого устройства позволяет запускать ваше приложение на ПК, планшетах и ​​мобильных телефонах (при минимальных затратах на порты между устройствами) и способных запускать в любом случае доступ к Интернету.

Я предлагаю вам, чтобы догнать и узнать много о веб-сервисы, Json, JS библиотеки JQuery, Сэмми и некоторые интересные вещи, как Knockout, SPA, угловой, узел и т.д.

Редактировать, ответ на комментарии

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

Silverlight. Как не любить его? В специальном после борьбы со вспышкой. Стыдно MS вытащил вилку (умереть в ад MS CEO). Когда MS позволила ему умереть, я планировал большой веб-приложение SL - это мой первый выбор. Почему я передумал? Ну, 2 года, чтобы разработать это приложение, и в конце, сколько браузеру не удалось его поддержать? Сообщество SL замечательно, инструмент отличный, но браузеры могут просто сказать: «Эй, завтра нет гарантии, что он будет работать.

.Net и MS-платформы. Я разработчик .Net. Я принял его с бета-тестирования, сначала для работы с winforms (в предыдущей жизни я был гордым разработчиком Delphi). Через некоторое время начал работать с сетью. Я также работал в классическом ASP (неудачные времена) и любил .Net ASP с самого начала.

Вы можете запускать приложения .Net практически на любом ПК на планете сегодня. Не совсем верно для всех мобильных телефонов/гаджетов. Для браузеров чистый HTML + JS + CSS плохо подходит, потому что он легкий (сделано правильно). Кроме того, мы можем переместить много вещей на клиентскую сторону и просто позволить ему попасть на сервер только тогда, когда это необходимо. .Net приложения могут сделать это, конечно, но плохо никогда не быть легким, как разработанный HTML + JS + CSS.

На самом деле я считаю, что вы можете делать что-либо с .Net, и вы можете делать удивительные вещи, если у вас есть несколько хороших разработчиков в вашей команде. Но в зависимости от проекта больно лучше (и дешевле) в HTML или PHP или Ruby или Java и т. Д.

Фактически в предыдущем магазине, с командами PHP и .Net, мы обнаружили (после изучения в течение 1 года, метрики, много проектов), небольшие проекты лучше выполняются на PHP, более крупные в .Net (если я помню, средний проект может составлять от 4 до 6 тыс. человек/час).

Пункт здесь. Вы действительно должны много читать о HTML, CSS, JS, SPA, Angular и т. Д. Привлечение к жизни большого и сияющего веб-приложения сегодня бросает вызов не тому, что мы можем делать (мы можем делать все), но как мы можем это сделать. DDD, MVC, MVVM. Рамки тестирования и т. Д. Man Node - будущее (по крайней мере, концепция).

Веб-разработка действительно изменилась за последние годы, а вместе с ней и ожидания клиентов и пользователей. Сегодня никто не боится ждать более 2 секунд для загрузки страницы. Все хотят, чтобы юзабилити находилось в верхней части таблицы от царапины проекта. Приложение должно быть отзывчивым и т. Д. (Не используя здесь гулдистские слова руководства Дилбертиана. Простое указание на удобство использования - это важно сегодня). И не забывайте, что каждый хочет, чтобы он был битым (с точки зрения графического дизайнера), даже если это тупой B2B, который должен использоваться только пещерными мужчинами.

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