eRKa

Любую задачу можно эффективно решить и под core и под java. Но как по мне, то на C# мне надо меньше телодвижений делать и есть моменты, которые работают эффективнее, чем в java (все-таки C# помоложе и учитывал ошибки конкурентов). Плюс java более инертная, .net развивается быстрее, быстрее реагирует на потребности и если говорить об enterprise, то я считаю, что у .net перспектив больше.

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

public string ResponseData(object value)
{
	retrun JsonConvert.Serialaze(value);
}

Теперь мы может одним методом отправить хоть объект, хоть значимый тип. Если бы не было упаковки, пришлось бы писать кучу перегрузок для метода.

Это называется построение траектории с буфером. Для этого, на основе траектории и буфера строится полигон, а затем уже стандартный алгоритм вхождения точки в полигон.

Самому писать трансформацию линии в полигон - это гемор еще тот, я пытался). По точкам строятся окружности, потом прямоугольники по линиям, потом делается триангуляция, потом удаляются все внутренние треугольники. Но это еще пол беды, потому что есть разница в расстоянии на градус на севере и юге и учитывать в каждой точке полигона этот коэффициент у меня не получилось, в общем кривой полигон получался. Писал я на C# и я не нашел библиотеки, которая бы это делала. Зато я нашел такую на js turf . Когда клиент строит траекторию, указывает буфер, то при сохранении полигон строится на клиенте и уже трансформированный geojson отправляется на сервер.

Полигон из траектории с буфером я делал так

var lineWithBuffer = turf.buffer(line, buffer, 'meters');
geo.features[i].geometry = lineWithBuffer.geometry;

Вы не указали яп. В C# это решается одной строкой кода

File.ReadLines(pathToTextFile)
	.SkipWhile(line => !line.Contains("word"))  // пропустит строки по условию
	.Skip(count)        // сколько строк пропустить надо
	.TakeWhile(line => line.Contains("word"))  // берет строки по условию
	.Take(count)        // сколько строк взять надо

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

Атрибут 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.

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

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

Если просто для информации
Image myImg = Image.FromFile("path here");
Затем здесь.
А в общем здесь.
Bitmap нужен, если Вы с изображением что-то хотите сделать.

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

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);

У Вас идет ожидание ввода Console.ReadLine(), это блокирует дальнейшее выполнение.