Нет необходимости делать API и его согласовывать. React или Angular - это есть API, которое мы дергаем и отрисовываем ответы, надо поменять API, надо переделывать на двух сторонах.
В Blazor Server можно грубо говоря в коде компонента прочитать записи из базы данных и циклом отрисовать их сразу в таблицу. А при нажатии на кнопку сразу отправить изменения в базу. Для условного MVP это позволяет делать за часы то, что на связке Angular/React занимает дни. И переделывать опять же за часы.
Можно использовать объекты доменной области, внутренние классы и базу кода компании, т.е. достигается полное переиспользования кода, без дублирования код бэка/код фронта.
В ряде регионов айтишники могут патент получить, с фиксированными платежами. В Питере 5 тысяч в месяц. Если уж совсем хочешь сэкономить, можно патент только на те месяцы оформлять когда деньги выводить будешь, а между ними на бирже держать.
Грубо говоря, суть MVVM в том, что используете ViewModel в качестве связки между UI и доменной областью. Между UI и ViewModel организуется двухсторонний биндинг, который автоматически обновляет UI при изменении данных, а данные из UI через ViewModel идут обратно в доменную область. Валидация как правило тоже делается на уровне ViewModel.
При этом получается что у вас .xaml.cs практически пустой, все привязки задаются в xaml файле.
Click вообще не следует использовать, вместо этого есть команды. Есть стандартный паттерн RelayCommand (аналог DelegateCommand из майкрософтовского Prism):
RelayCommand
public class RelayCommand : ICommand
{
#region Fields
readonly Action<object> _execute;
readonly Predicate<object> _canExecute;
#endregion // Fields
#region Constructors
/// <summary>
/// Creates a new command.
/// </summary>
/// <param name="execute">The execution logic.</param>
/// <param name="canExecute">The execution status logic.</param>
public RelayCommand(Action<object> execute, Predicate<object> canExecute = null)
{
if (execute == null)
throw new ArgumentNullException("execute");
_execute = execute;
_canExecute = canExecute;
}
#endregion // Constructors
#region ICommand Members
[DebuggerStepThrough]
public bool CanExecute(object parameter)
{
return _canExecute == null || _canExecute(parameter);
}
public event EventHandler CanExecuteChanged
{
add { CommandManager.RequerySuggested += value; }
remove { CommandManager.RequerySuggested -= value; }
}
public void Execute(object parameter)
{
_execute(parameter);
}
#endregion // ICommand Members
}
Во ViewModel у вас есть
class ViewModel
{
public ICommand DigitButtonCommand
{
get;
}
public ViewModel()
{
DigitButtonCommand = new RelayCommand((arg) => { });
}
}
Соответственно во вьюшке вы привязываете свойство DigitButtonCommand:
, а в родительскую ViewModel добавляются свойства для биндинга ContentControl'ов:
/// <summary>
/// Get or set left panel.
/// </summary>
public object Left
{
get
{
return _left;
}
set
{
_left = value;
OnPropertyChanged();
}
}
/// <summary>
/// Get or set center panel.
/// </summary>
public object Center
{
get
{
return _center;
}
set
{
_center = value;
OnPropertyChanged();
}
}
/// <summary>
/// Get or set right panel.
/// </summary>
public object Right
{
get
{
return _right;
}
set
{
_right = value;
OnPropertyChanged();
}
}
Магия начинается в тот момент, когда вы присваиваете, например свойству Left, дочернюю ViewModel типа MainButtonsViewModel. В этот момент WPF найдёт вьюшку в словаре (словарь должен быть подключен к ресурсам родительской вьюшки), которая соответствует MainButtonsViewModel (в данном случае MainButtons.xaml) и автоматически отобразит её в соответствующем ContentControl.
При этом вы работаете только с ViewModel, вам не надо заботиться об отображениях текста, о сокрытии контролов в рамках UI и т.п. Всё ваше приложение разделено на атомарные компоненты, каждый из которых имеет свою зону ответственности.
Предполагаю, что основные проблемы с вистой были вызваны тем, что в тот момент Microsoft начинала переходить на новый стек разработки десктопных приложений. Если XP и предыдущие системы использовали для отрисовки GDI32, то виста уже работала через DirectX, отсюда требования к видеокарте.
Параллельно с вистой вышла 3 версия .net Framework, включающая в себя совершенно новую технологию WPF (Windows Presentation Foundation), которую допилили до ума к 7 и которая активно используется во всех последующих системах.
Не используйте событие Click на кнопке, для этого есть команды. Они отлично сочетаются с паттерном MVVM и служат для разделения ответственности.
В правильно разработанном WPF приложении, .xaml.cs файлы, в большинстве случаев, содержат только код, сгенерированный студией, логика вынесена во ViewModel. И наследуются, соответственно ViewModel, а не вьюшки.
Я могу вам рассказать про .net, я не изучал глубоко UWP приложения, так как не было пока проектов, связанных с ним.
.net же огромная платформа, которая делится на множество направлений.
Изначально были Windows.Forms, Asp.Net Web Forms, .net CE, .net embedded. Потом появились WPF, WCF, WWF, ASP.NET MVC. Windows CE канул в Лету и на смену ему пришёл .net под Windows Phone, сейчас активно развивается UWP (в рамках мобильных платформ) и Asp.Net Web API (в рамках веба), выделившийся из ASP.NET MVC. Сейчас активно .net Core развивается. Из этого списка я вообще не трогал UWP, .net Embedded и чуть-чуть трогал .net Core. Про остальное спрашивайте, расскажу.
Я, честно говоря, не изучал его глубоко, не приходилось сталкиваться. Но предполагаю что там идеология похожая.
Есть ещё Apache Cordova, там можно, насколько я понимаю на JS писать.
Но опять же, у .net идеология, что всё компилируется в байт-код MSIL (а-ля ассемблер), который затем, во время исполнения, компилируется в нативный код, специфичный для платформа. Скорее всего, там просто сделан компилятор, который превращает JS в MSIL (байт-код).
Я могу сказать рамках .net, котором пишу. Там такого нет. Есть основная технология, WPF (Windows Presentation Foundation), которая использует паттерн MVVM. Первая версия вышла 2006 году, в дальнейшем вносились косметические изменения. Она позволяет использовать весь функционал .net Framework. Есть библиотеки дополнительных контролов, выпускаемых различными вендорами, типа Telerik, но их использование опционально.
Фактически, все новые приложения на платформах MS (Windows 10, Windows.Store, Windows.Phone, Silverlight) пишутся на WPF, который стандартизирован.
При этом новые технологии, появляющиеся в рамках .net framework (async/await, EntityFramework) вплетаются в WPF без нарушения обратной совместимости.
Вот не уверен я, честно говоря. В языке программирования должна быть стройность и логичность, «внутренняя красота», если можно так сказать. Начиная использовать какую-то новую функциональность языка, в хорошем языке интуитивно понимаешь, что тебя ждёт: как примерно реализован интерфейс, какие методы потокобезопасны, какие нет, как будет проходить обработка ошибок и т.д.
В javascript этого нет и никогда не было. Те же == и ===, null и undefined, родовая травма в виде isNan. Чтобы на нём писать, его надо заучивать, реально. Нужно помнить, что при == будет приведение типов, а при === не будет. Нужно помнить, что в объекте error есть свойство message, которое хранит сообщение об ошибке. Нужно помнить, что проверять есть ли свойство нужно через if(foo.bar), потому что сравнения с null или undefined будет недостаточно. На том же хабре полно статей о подводных камнях js.
Это палка о двух концах, имхо. Тогда не было технологий и альтернатив и да, приходилось пользоваться кривым Prototype и тратить кучу времени на то, что сейчас можно сделать за час (та же сборка проекта).
С другой стороны, тогда и порог вхождения был гораздо ниже, изучаешь синтаксис языка, читаешь документацию к Prototype и вперёд фигачить.
То что происходит сейчас замечательно описано в статье, её показать человеку, который только входит во фронтэнд, он с высокими шансами станет как бабушкин мальчик. Делается то всё просто, если знаешь как, а чтобы во вё разобраться надо немеряно времени потратить. Т.е. порог вхождения вырос на порядок как минимум.
Нету сейчас другого языка для веба, к сожалению, поэтому и появляются костыли. Они реально необходимы, потому что без них нормального приложения в 2016 не напишешь. Но костыли никогда не заменят живые ноги, и мне грустно от того, что и попыток создать язык с ногами не особо заметно :(
21, если быть точным. И в чём он конкретно изменился? «use strict»; появился?
Сейчас на нём можно писать приложения любой степени сложности используя все те костыли, которые указаны в статье. Хотя это не верно, у JS есть принципиальные ограничение, например он не работает с файловой системой, в самом языке нет такой функциональности, она реализуется за счёт внешних модулей (например в составе NodeJs) и в принципе не реализована в среде веб-браузера. То же самое относится к хранению данных, есть внешние библиотеки, реализующие доступ к LocalStorage браузера и базе данных, но это не часть языка, это именно внешняя библиотека, которая в одних браузерах реализована, а в других нет.
JavaScript — это костыль на костыле, пирамида костылей. Хотите что-то реализовать — не забудьте заглянуть на http://caniuse.com чтобы проверить, где эти костыли реализованы.
Нет необходимости делать API и его согласовывать. React или Angular - это есть API, которое мы дергаем и отрисовываем ответы, надо поменять API, надо переделывать на двух сторонах.
В Blazor Server можно грубо говоря в коде компонента прочитать записи из базы данных и циклом отрисовать их сразу в таблицу. А при нажатии на кнопку сразу отправить изменения в базу. Для условного MVP это позволяет делать за часы то, что на связке Angular/React занимает дни. И переделывать опять же за часы.
Можно использовать объекты доменной области, внутренние классы и базу кода компании, т.е. достигается полное переиспользования кода, без дублирования код бэка/код фронта.
Одна из немногих книг, которую я бросил, не дочитав. Сплошное нытьё автора и ничего дельного.
При этом получается что у вас .xaml.cs практически пустой, все привязки задаются в xaml файле.
Click вообще не следует использовать, вместо этого есть команды. Есть стандартный паттерн RelayCommand (аналог DelegateCommand из майкрософтовского Prism):
Во ViewModel у вас есть
Соответственно во вьюшке вы привязываете свойство DigitButtonCommand:
CommandParameter придёт в качестве аргумента в обработчик (в данном случае 7).
Самое интересное во всём этом, что вы можете создавать дочерние вьюшки, используя ViewModel.
В родительскую вьюшку кладётся ContentControl:
В ресурсах задаётся шаблон:
, а в родительскую ViewModel добавляются свойства для биндинга ContentControl'ов:
Магия начинается в тот момент, когда вы присваиваете, например свойству Left, дочернюю ViewModel типа MainButtonsViewModel. В этот момент WPF найдёт вьюшку в словаре (словарь должен быть подключен к ресурсам родительской вьюшки), которая соответствует MainButtonsViewModel (в данном случае MainButtons.xaml) и автоматически отобразит её в соответствующем ContentControl.
При этом вы работаете только с ViewModel, вам не надо заботиться об отображениях текста, о сокрытии контролов в рамках UI и т.п. Всё ваше приложение разделено на атомарные компоненты, каждый из которых имеет свою зону ответственности.
Параллельно с вистой вышла 3 версия .net Framework, включающая в себя совершенно новую технологию WPF (Windows Presentation Foundation), которую допилили до ума к 7 и которая активно используется во всех последующих системах.
В правильно разработанном WPF приложении, .xaml.cs файлы, в большинстве случаев, содержат только код, сгенерированный студией, логика вынесена во ViewModel. И наследуются, соответственно ViewModel, а не вьюшки.
Можно просто тип any использовать
.net же огромная платформа, которая делится на множество направлений.
Изначально были Windows.Forms, Asp.Net Web Forms, .net CE, .net embedded. Потом появились WPF, WCF, WWF, ASP.NET MVC. Windows CE канул в Лету и на смену ему пришёл .net под Windows Phone, сейчас активно развивается UWP (в рамках мобильных платформ) и Asp.Net Web API (в рамках веба), выделившийся из ASP.NET MVC. Сейчас активно .net Core развивается. Из этого списка я вообще не трогал UWP, .net Embedded и чуть-чуть трогал .net Core. Про остальное спрашивайте, расскажу.
Есть ещё Apache Cordova, там можно, насколько я понимаю на JS писать.
Но опять же, у .net идеология, что всё компилируется в байт-код MSIL (а-ля ассемблер), который затем, во время исполнения, компилируется в нативный код, специфичный для платформа. Скорее всего, там просто сделан компилятор, который превращает JS в MSIL (байт-код).
Фактически, все новые приложения на платформах MS (Windows 10, Windows.Store, Windows.Phone, Silverlight) пишутся на WPF, который стандартизирован.
При этом новые технологии, появляющиеся в рамках .net framework (async/await, EntityFramework) вплетаются в WPF без нарушения обратной совместимости.
В javascript этого нет и никогда не было. Те же == и ===, null и undefined, родовая травма в виде isNan. Чтобы на нём писать, его надо заучивать, реально. Нужно помнить, что при == будет приведение типов, а при === не будет. Нужно помнить, что в объекте error есть свойство message, которое хранит сообщение об ошибке. Нужно помнить, что проверять есть ли свойство нужно через if(foo.bar), потому что сравнения с null или undefined будет недостаточно. На том же хабре полно статей о подводных камнях js.
С другой стороны, тогда и порог вхождения был гораздо ниже, изучаешь синтаксис языка, читаешь документацию к Prototype и вперёд фигачить.
То что происходит сейчас замечательно описано в статье, её показать человеку, который только входит во фронтэнд, он с высокими шансами станет как бабушкин мальчик. Делается то всё просто, если знаешь как, а чтобы во вё разобраться надо немеряно времени потратить. Т.е. порог вхождения вырос на порядок как минимум.
Сейчас на нём можно писать приложения любой степени сложности используя все те костыли, которые указаны в статье. Хотя это не верно, у JS есть принципиальные ограничение, например он не работает с файловой системой, в самом языке нет такой функциональности, она реализуется за счёт внешних модулей (например в составе NodeJs) и в принципе не реализована в среде веб-браузера. То же самое относится к хранению данных, есть внешние библиотеки, реализующие доступ к LocalStorage браузера и базе данных, но это не часть языка, это именно внешняя библиотека, которая в одних браузерах реализована, а в других нет.
JavaScript — это костыль на костыле, пирамида костылей. Хотите что-то реализовать — не забудьте заглянуть на http://caniuse.com чтобы проверить, где эти костыли реализованы.