DailyDDose

Если это sql, то может просто использовать каскадное удаление!?

Зависит от БД. Гуглить Recursive CTE(Common Table Expressions).
В целом SQL выглядит примерно так

with recursive cte (id, name, parent_id) as
(
 select     id,
            name,
            parent_id
 from       products
 where      parent_id = 19
 union all
 select     p.id,
            p.name,
            p.parent_id
 from       products p
 inner join cte
         on p.parent_id = cte.id
)
select * from cte;

_context.Entry(userData).State = EntityState.Modified;
 try
{
    await _context.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException)
{
    if (!Db.Users.Any( a => a.Id==userData.Id))
    {
        return NotFound();
    }
    else
    {
        throw;
    }
}

Надо уточнять model/db first, но судя по всему model. Такие вещи обычно руками не пишут, а используют Add-Migration -Name AddFieldAvatarToUsersTable.
Ну а по сути вопроса:

AddColumn("dbo.users", "avatar", c => c.string(nullable: false, defaultValueSql: "default.jpg"));

и

DropColumn("dbo.users", "avatar");

Как генераторы для бедных (вообще ценность async/await довольно сомнительна, после введения генераторов).
Под капотом все это дело преобразовывается в машину состояний, с сохранением стека при переключении.
Чтобы лучше понять данный механизм, посмотрите как работают транспиляторы babel или typescript
Например typescript преобразует ваш код в

var __awaiter = (this && this.__awaiter) || function (thisArg, _arguments, P, generator) {
    return new (P || (P = Promise))(function (resolve, reject) {
        function fulfilled(value) { try { step(generator.next(value)); } catch (e) { reject(e); } }
        function rejected(value) { try { step(generator["throw"](value)); } catch (e) { reject(e); } }
        function step(result) { result.done ? resolve(result.value) : new P(function (resolve) { resolve(result.value); }).then(fulfilled, rejected); }
        step((generator = generator.apply(thisArg, _arguments || [])).next());
    });
};
var __generator = (this && this.__generator) || function (thisArg, body) {
    var _ = { label: 0, sent: function() { if (t[0] & 1) throw t[1]; return t[1]; }, trys: [], ops: [] }, f, y, t, g;
    return g = { next: verb(0), "throw": verb(1), "return": verb(2) }, typeof Symbol === "function" && (g[Symbol.iterator] = function() { return this; }), g;
    function verb(n) { return function (v) { return step([n, v]); }; }
    function step(op) {
        if (f) throw new TypeError("Generator is already executing.");
        while (_) try {
            if (f = 1, y && (t = y[op[0] & 2 ? "return" : op[0] ? "throw" : "next"]) && !(t = t.call(y, op[1])).done) return t;
            if (y = 0, t) op = [0, t.value];
            switch (op[0]) {
                case 0: case 1: t = op; break;
                case 4: _.label++; return { value: op[1], done: false };
                case 5: _.label++; y = op[1]; op = [0]; continue;
                case 7: op = _.ops.pop(); _.trys.pop(); continue;
                default:
                    if (!(t = _.trys, t = t.length > 0 && t[t.length - 1]) && (op[0] === 6 || op[0] === 2)) { _ = 0; continue; }
                    if (op[0] === 3 && (!t || (op[1] > t[0] && op[1] < t[3]))) { _.label = op[1]; break; }
                    if (op[0] === 6 && _.label < t[1]) { _.label = t[1]; t = op; break; }
                    if (t && _.label < t[2]) { _.label = t[2]; _.ops.push(op); break; }
                    if (t[2]) _.ops.pop();
                    _.trys.pop(); continue;
            }
            op = body.call(thisArg, _);
        } catch (e) { op = [6, e]; y = 0; } finally { f = t = 0; }
        if (op[0] & 5) throw op[1]; return { value: op[0] ? op[1] : void 0, done: true };
    }
};
var _this = this;
var sleep = function (ms) { return new Promise(function (resolve) { return setTimeout(resolve, ms); }); };
(function () { return __awaiter(_this, void 0, void 0, function () {
    return __generator(this, function (_a) {
        switch (_a.label) {
            case 0:
                setTimeout(function () { return console.log('1000'); }, 1000);
                return [4 /*yield*/, sleep(5000)];
            case 1:
                _a.sent();
                console.log('5');
                return [2 /*return*/];
        }
    });
}); })();

Браузерные движки и nodejs делают под капотом примерно тоже самое.

> Минимум 8 часов, чтобы были деньги.

Работать нужно не 8 часов, а головой.

Вам бы основы JavaScript подтянуть.
Во-первых вы биндите контекст хандлера на AppField в конструкторе:

constructor(props) {
  super(props);
  this.state = props.params;
  this.onFieldChange = this.onFieldChange.bind(this); // тут
}

Во-вторых, вы определяте переменную self, ссылающуюся на this и она ни делает ровным счетом ничего, так как вы передаете функцию в колбек обработчика события:

renderSingleValue(data = {}) {
  ...
  let self = this;  // бессмысленно

  return (
    <input type="text"
      ...
      onChange={self.onFieldChange} 
      ...
    />
  );
}

Даже если бы функция не была забинжена на AppField, у вас бы все-равно ничего не получилось.

В-третих, значение инпутов лучше хранить в родителе, а не в самих инпутах.

Трюк с self работает в отложенных вызовах:

constructor() {
  const self = this;

  node.addEventListener('click', function() {
    self.handleEvent();  // сработает, так как функция вызывается на self
  });
}

и не сработает при передаче функции:

constructor() {
  const self = this;

  node.addEventListener('click', self.handleEvent);  // не сработает, функция передается
                                                     // в колбек обработчика события
}                                                    // и не будет вызываться на self

Пример как можно сделать контролируемую форму с состоянием инпутов в родителе:

class Example extends Component {
  state = {
    inputValue: '',
  };

  handleChange = e => {  // arrow class field function биндится на контекст экземпляра
    const { name, value } = e.target;
    
    this.setState({
      [name]: value,
    });
  };

  render() {
    const { inputValue } = this.state;

    return (
      <Wrapper>
        <input
          name="inputValue"
          value={inputValue}
          onChange={this.handleChange}
        />
        ...
      </Wrapper>
    );
  }
}

Аналогичное решение без использования class field function:

class Example extends Component {
  constructor(props) {
    super(props);
    this.state = {
      inputValue: '',
    };
    this.handleChange = this.handleChange.bind(this);
  }
  

  handleChange(e) {
    const { name, value } = e.target;
    
    this.setState({
      [name]: value,
    });
  }

  render() {
    const { inputValue } = this.state;

    return (
      <Wrapper>
        <input
          name="inputValue"
          value={inputValue}
          onChange={this.handleChange}
        />
        ...
      </Wrapper>
    );
  }
}

Если делаете совой компонент вроде кастомного select, то вы можете в его реализации по изменению сами вызывать хандлер onChange, передавая туда фейковое событие с нужными вам ключами:

handleChange = value => {
  const { name, onChange } = this.props;
  const fakeEvent = { target: { name, value } };

  onChange(fakeEvent);
};

1. Если попытаетесь изменить this.props, получите исключение:
Cannot assign to read only property
2. У вас есть возможность мутировать state, вот только делать это не нужно.

Хороший способ управления состоянием компонентов через родителя:

class Example extends Component {
  state = {
    inputValue: '',
  };

  handleChange = e => { 
    const { name, value } = e.target;
    
    this.setState({
      [name]: value,
    });
  };

  render() {
    const { inputValue } = this.state;

    return (
      <Wrapper>
        <input
          name="inputValue"
          value={inputValue}
          onChange={this.handleChange}
        />
        ...
      </Wrapper>
    );
  }

async/await лишь удобная обертка над промисами. Подробней о async/await можете почитать тут.
1000 выводится раньше потому, что функция, благодаря использованию ключевого слова await, дожидается ответа от Promise возвращаемого функцией sleep и только после этого продолжает выполнение.
В V8 async/await так же как и Promise реализованы на JavaScript. С реализацией можно ознакомиться тут.
Как можно видеть реализована она на генераторах.

Аналог вашего примера без использования async/await:

const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));

(() => {
    setTimeout(() => console.log('1000'), 1000);
    sleep(5000).then(() => {
      console.log('5');
    });
})();

Так же async function всегда возвращает Promise, даже если вы ничего не возвращаете.

SQL Server is configured to allow remote connections

Я бы выбрал первый вариант, а вопрос с интеграционными тестами решил бы разделением на сьюты (можно их в разные папки положить.

Т.е. будет так:

MainProject/Program.cs

и тесты на этот класс будут

MainProject.Tests/Unit/ProgramTest.cs
MainProject.Tests/Integration/ProgramTest.robot

Мы используем и в крупных проектах тоже.

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

Windows Forms устаревшая технология. Сейчас для десктопа под виндовс разрабатываются на WPF. Там спецом все сделано для возможности гибкого дизайна.

Атрибут FromBody может применяться только к одному параметру. Он нужен, когда Вы в теле передаете параметр простого типа. Если Вам нужно отправить несколько параметров пост запросом, сделайте сложный тип (dto, viewModel, как нравится)

public class AuthorizeModel
{
	public string Login { get; set; }
	public string Password { get; set; }
}

В этом случае атрибут можно не указывать.
Вот тут подробности.

Web API reads the response body at most once, so only one parameter of an action can come from the request body. If you need to get multiple values from the request body, define a complex type.

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

if (handler.CanHandle(socket, messageType, server))
{
	handler.Handle(socket, webSocketMessage, server);
	return;
}

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

public BaseHandler HandlerFactory(messageType)
	switch(messageType)
	{
		case ChatMessage.Type:
			retun new ChatHandler();
			break;
		case AuthMessage.Type:
			retun new AuthHandler();
			break;
		...
	}
}

var handler = Successor.HandlerFactory(messageType);
handler.Handle(socket, webSocketMessage, server);

Ну или на крайняк без этого фора

var handler = Handlers.FirstOdefault(x => x.CanHandle(socket, messageType, server));
if(handle != null)
	handler.Handle(socket, webSocketMessage, server);

Или сделайте из списка хендлеров дикшинари

Handlers[messageType].Handle(socket, webSocketMessage, server);

Лично я бы использовал фабрику, только в данном случае без лишних созданий экземпляров, это выглядит проще и понятнее, добавить в нее еще один хендлер - это две строки кода.
Если Вас смущает статический класс, сделайте синглтон. По факту фабрики обычно и делают синглтонами.
Если везде смущает три параметра в конструкторе (socket, messageType, server), оберните их в фасад

class HandlerParam
{
	public IWebSocketConnection socket { get; set; }
	public string webSocketMessage { get; set; }
	public IServer server { get; set; }
}

var handlerParam = new HandlerParam
{
	...
}

handler.Handle(handlerParam);