Я бы сказал что automapper позволяет условно экономить время для простых моделек. Как только модельки становятся сложнее, с условными маппингами и конвертациями, кода приходится писать больше.
Мы в итоге где это возможно избавлялись от него полностью, благо есть source generators.
. net Core - это отдельная open source версия .net, поддерживаемая Майкрософт. Появилась в 2016 году. Разработка старого .net Framework остановлена, к нему максимум патчи выходят, всё новое на .net Core. .net Core не привязан к винде, работает на линуксе, на андроиде и айфоне и в браузере через Web Assembly. .net библиотека без специфических платформенных зависимостей запускается везде. Ну и в целом очень много разработчиков пишут на Винде/маке, а потом тот же код запускается в докере на Линукс контейнерах
А вы пользовательские соглашения облачных провайдеров читали? Те, где написано что они ни за что не отвечают, могут в любой момент заблокировать инфраструктуру, предоставляют сервисы "как есть" и удерживают все деньги при блокировке в качестве "штрафа". В соглашении vk cloud так и написано.
То же самое с SLA, которое звучит красиво, но его нарушение со стороны провайдера предполагает компенсацию оплаты облака, а не компенсацию реальных убытков заказчика от неработоспособности облака.
Я не супер силён в плюсах, но в .net есть классы и структуры. Массив классов хранит ссылки на экземпляры классов (последовательно), но сами данные по ссылкам могут находиться в разных местах. Массив структур хранит данные внутри себя и данные лежат последовательно. Предполагаю что в плюс при хранении ссылок в массиве, сами данные тоже могут быть размазаны по всей памяти, в зависимости от времени создания конкретного экземпляра, на который ссылается элемент массива.
Озон не показывает ту цену, которая выставлена у продавца. Условно товар выставлен продавцом за 2000 рублей, а озон показывает цену для покупателя 1800 рублей. Или 1500 рублей, если например реклама продавцом включена. Т.е. реальная комиссия может быть 45-47 процентов, но озон снижает снижает цену в рамках комиссии, начислят продавцу внутренние баллы, которые уходят на оплату комиссии озон. На вб примерно та же история
Бининг физически невозможно отключить. Линзы пикселей на самой матрице окрашены в красный, синий и зелёный цвета и объединены в группы по 16 штук. Получается 12,5 условно честных мегапикселей, когда одна группа из 16 пикселей воспринимается как 1 пиксель. 50 мегапикселей - это восприятие 16 пикселей как 4, с увеличением детализации, но потерей качества, потому что соседние 12 пикселей окрашены в тот же цвет. 200 мегапикселей - один физический пиксель превращается в один пиксель на изображении. Детализация возрастает, но с ещё большей потерей качества.
А толку то от размера сенсора, если для его полноценного использования необходимо линзу удалять от него? Дюймовые сенсоры - это именно маркетинговый прием, они действительно ставятся, но используется только их часть, не весь сенсор целиком. На профессиональных фотообъективах передняя линза находится в сантиметрах от сенсора, что позволяет проецировать свет на весь сенсор. В смартфонах линза находится в миллиметрах, что позволяет проецировать свет на кратно меньший сенсор, либо на часть площади крупного сенсора.
Нет необходимости делать 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. Про остальное спрашивайте, расскажу.
Я бы сказал что automapper позволяет условно экономить время для простых моделек. Как только модельки становятся сложнее, с условными маппингами и конвертациями, кода приходится писать больше.
Мы в итоге где это возможно избавлялись от него полностью, благо есть source generators.
. net Core - это отдельная open source версия .net, поддерживаемая Майкрософт. Появилась в 2016 году. Разработка старого .net Framework остановлена, к нему максимум патчи выходят, всё новое на .net Core. .net Core не привязан к винде, работает на линуксе, на андроиде и айфоне и в браузере через Web Assembly. .net библиотека без специфических платформенных зависимостей запускается везде. Ну и в целом очень много разработчиков пишут на Винде/маке, а потом тот же код запускается в докере на Линукс контейнерах
А вы пользовательские соглашения облачных провайдеров читали? Те, где написано что они ни за что не отвечают, могут в любой момент заблокировать инфраструктуру, предоставляют сервисы "как есть" и удерживают все деньги при блокировке в качестве "штрафа". В соглашении vk cloud так и написано.
То же самое с SLA, которое звучит красиво, но его нарушение со стороны провайдера предполагает компенсацию оплаты облака, а не компенсацию реальных убытков заказчика от неработоспособности облака.
Я не супер силён в плюсах, но в .net есть классы и структуры. Массив классов хранит ссылки на экземпляры классов (последовательно), но сами данные по ссылкам могут находиться в разных местах. Массив структур хранит данные внутри себя и данные лежат последовательно. Предполагаю что в плюс при хранении ссылок в массиве, сами данные тоже могут быть размазаны по всей памяти, в зависимости от времени создания конкретного экземпляра, на который ссылается элемент массива.
Это не капитализм так работает, это некоторая часть менеджмента воспринимает сотрудников не как людей, а как ресурс.
Ну да, так и есть
Озон не показывает ту цену, которая выставлена у продавца. Условно товар выставлен продавцом за 2000 рублей, а озон показывает цену для покупателя 1800 рублей. Или 1500 рублей, если например реклама продавцом включена. Т.е. реальная комиссия может быть 45-47 процентов, но озон снижает снижает цену в рамках комиссии, начислят продавцу внутренние баллы, которые уходят на оплату комиссии озон. На вб примерно та же история
Бининг физически невозможно отключить. Линзы пикселей на самой матрице окрашены в красный, синий и зелёный цвета и объединены в группы по 16 штук. Получается 12,5 условно честных мегапикселей, когда одна группа из 16 пикселей воспринимается как 1 пиксель. 50 мегапикселей - это восприятие 16 пикселей как 4, с увеличением детализации, но потерей качества, потому что соседние 12 пикселей окрашены в тот же цвет. 200 мегапикселей - один физический пиксель превращается в один пиксель на изображении. Детализация возрастает, но с ещё большей потерей качества.
А толку то от размера сенсора, если для его полноценного использования необходимо линзу удалять от него? Дюймовые сенсоры - это именно маркетинговый прием, они действительно ставятся, но используется только их часть, не весь сенсор целиком. На профессиональных фотообъективах передняя линза находится в сантиметрах от сенсора, что позволяет проецировать свет на весь сенсор. В смартфонах линза находится в миллиметрах, что позволяет проецировать свет на кратно меньший сенсор, либо на часть площади крупного сенсора.
Нет необходимости делать 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. Про остальное спрашивайте, расскажу.