Александр Юдаков

Во ViewModel можно же сделать спец свойство, которое будет биндиться к ToolTip и это свойство можно обновлять в зависимости каких либо условий. Это вам позволит не создавать новое св-во в самой модели. Вы вызываете свой статический метод во ViewModel и результат присваиваете этому св-ву.

Хочу пруфлинк, от куда такая инфа, что сущности не могут быть моделями ORM и иметь внешние ключи. Как по мне, то это полный бред, потому что сущностями как раз называют базовые модели предметной области, которые как раз зачастую являются мапингом таблиц из БД, а соответственно имею внешние ключи.

Именно поэтому основная ORM в .net носит название Entity Framework, а ее модели называют сущностями.

Вот определение модели-сущности:

Любой фрагмент предметной области может быть представлен как множество сущностей, между которыми существует некоторое множество связей.

Сущность (entity) - это объект, который может быть идентифицирован неким способом, отличающим его от других объектов. Примеры: конкретный человек, предприятие, событие и т.д.

Набор сущностей (entity set) - множество сущностей одного типа (обладающих одинаковыми свойствами). Примеры: все люди, предприятия, праздники и т.д. Наборы сущностей не обязательно должны быть непересекающимися. Например, сущность, принадлежащая к набору МУЖЧИНЫ, также принадлежит набору ЛЮДИ.

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

И напоследок тут.

https://msdn.microsoft.com/en-us/library/windows/d...

Чтобы чётко разделять внутреннюю реализацию и внешнее API

Да возможно.
Я изучал C++ и разработку ПО в целом самостоятельно. Первая книга по плюсам у меня была вот эта: https://www.amazon.com/Professional-C-Nicholas-Sol... . Довольно неплохая книга, не только о языке, но и о связанных областях, таких как проектирование, например. Правда сейчас новичкам я бы её не посоветовал.
Ну и чтобы самостоятельно освоить разработку ПО, вам необходима сильная мотивация и много времени. Сам по себе ЯП, к слову, это лишь малость. Вам необходимы знания о проектировании, архитектуре ПК, алгоритмах и структурах данных, тестировании и отладке, рекфаторинге и прочее. Я перечислил очень немногое, но всё это вам придётся изучать самостоятельно.

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

я чего-то не понимаю?

Определённо. Не понимаете разницу между minimum api и target api.

CommandHandler должен вернуть состояние операции.
В частности, если вместо исполнения команды, она ставится в очередь, надо вернуть токен.

По итогу имеем (к черту всех этих Янги и прочих) разделять разделить Command и Query невозможно - контракты идентичны.
Но это только в случае если ты собираешься CQRS имплементировать в реальном приложении, а не для написания очередной бестолковой статьи о сферическом коне в вакууме...

Вообще для сети boost.asio, прям совсем однозначно (кроссплатформенно, поддерживает IOCP, epoll, kqueue, неблокируемые сокеты, асинхронность), для многопоточности либо опять же boost, либо C++11, в вашем случае видимо boost (boost.thread, boost.atomic, boost.signals2), так же поглядите на tbb (неблокируемые очереди, алгоритмы и всё такое), легко, понятно, удобно.

Ну и если хотите на linux, то придется поддерживать и несколько компиляторов, а также и несколько стандартных библиотек.

1. Кривят мины при слове jquery только старые деды, потому что библиотека полезна и экономит много времени (особенно у новичков). Даже если эта библиотека будет объективно считаться полным дерьмом, какая вам разница если она решает ваши задачи?

2. Раньше говорили, vue используют там, где jquery уже не хватает. Я не понимал что это значит, столкнувшись с некоторыми задачами я понял смысл этой фразы. В действительности, если вам нужно повесить пару обработчиков на кнопки, формы и тд, vue вам не нужен. Если вам, как и мне, нужно подгружать постоянно обновляемые данные, всю эту информацию выводить в разных блоках, на каждый из который вешаются свои обработчики, когда появляются какие-то динамичные элементы в приложении и вы видите что в своем js-коде вы уже ничерта не можете разобраться, потому что вы пытались каждый модуль писать в отдельном файле и совмещать их вы уже не можете, вы открываете для себя vue-компоненты, за которыми легко следить и связывать между собой.

Сайт, что вы кинули - обычный лендос, прям обычный на все 167%. Для чего вам париться лепить компоненты в vue, если вам нужно написать 10 строк js кода? Конечно нет смысл использовать.

В качестве примера, для чего vue подошел бы, могу сказать то, что приходилось делать мне: есть проект с криптовалютой, который выводит кучу графиков по валюте, по каждому графику можно выбирать временной интервал и получать какие-то результирующие данные по этим интервалам. Для каждого блока начинка и обработчики разные (vue-компоненты), все это хранится в одном файле, отвечающий за каждый компонент. Помимо этих блоков есть некоторый объем периодично подгружаемой информации, которая тоже имеет вид графиков, круговых диаграмм итд. Все это прекрасно работало и на голом js, но когда проект стал разрастаться - в коде было уже сложно разбираться и я пытался сам писать какой-то аналог компонентов vue, понял что горожу велосипеды, перелез на vue и все.

99% программистов 90% времени занимаются отловом багов в махровом легайси или формошлёпством. Есть только один способ попасть в 1% настоящих творцов - быть творцом, способным написать что-нибудь поистине выдающееся.

Возвращать кастомные номера ошибок в принципе плохая практика.
Если у вас большой список параметров, то оборачивайте их в класс данных, dto.
Далее, вам нужна валидация. Из коробки доступна схема работы с ModelState - это когда в декларативном стиле описываются правила и на выходе есть метод isValid - валидна ли модель и весь список ошибок, если не валидна. Для зависимых полей приходится писать кастомные классы-валидаторы, это не всегда удобно, но можно писать правила любой сложности.
Второй вариант, это вы подключаете fluent validation, и во внешних классах описываете все правила. Как по мне, у них сложноватый синтаксис, поначалу немного пугающий, но в целом всё отлично работает.

void loop() {
  analogWrite(col, xCol);
  xBaza = Serial.read();
  if(xBaza != xBaza0) {
    xBaza0 = xBaza;
    analogWrite(baza, xBaza);
    writes();
  }
}

1. Попадаете в условие, выполняете действия. После чего идете на второй круг. в переменной сидит, например 50, которое вы присваиваете.
2. Снова читаете, но уже чтение порта возвращает вам -1, если не ошибаюсь, если не прочитано ни одного символа.
Сравниваем: -1 не равно 50 и вы опять в условии. Выполняется вывод и присваивание переменной значения -1.
После этого обе переменные становятся -1 и вы не попадаете в условие. Т.к. при попытке чтения порта результат -1 и в переменной тоже -1.

И читаете Вы не цифру, а ее ASCII код.

Возможно поможет if(xBaza != xBaza0 && xBaza != -1) {