eRKa

select vehicle.id, vehicle.mileage, vehicleType.name
from vehicle join vehicleType
on vehicle.vehicleTypeId = vehicleType.id

Он у Вас падает вот в этом месте

this.products = JSON.parse(localStorage['addbook']);

т.к при инициализации localStorage['addbook'] = "", а такое он не может преобразовать к json.

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

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

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

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

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

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

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

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

Для этого есть много вариантов:
1. Частичные представления. Просто, но логику надо писать внутри разметки, либо выносить наружу.
2. Html - хелперы.
3. Tag - хелперы.
4. View Component. Если требуется что-то с более сложной логикой, чем просто разметка, то лично я использую этот способ. Почитать за него можно тут.

А сам аякс трогать можно? Например так

function callback(data) { ... };
$.ajax({ ... }).then(function(data) { callback(data) });

А по поводу ajaxSuccess, то ответ аякса можно получить как текст из xhr.responseText.

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

При данном раскладе - никак. Вы учтите, что разоровская разметка во вьюшке выполняется на стороне сервера, она отрабатывает во время рендеринга html разметки на основе кода cshtml, а js код выполняется на стороне клиента и он ничего не знает о Вашем dictionary.

Я вижу, как вариант решения, Вашу таблицу выводить как частичное представление и при каждом добавлении/удалении строки делать запрос на сервер с параметрами новой строки и он будет возвращать новую таблицу, ну и соответственно dictionary будет обновляться.

Второй вариант, при добавлении строки делать аякс запрос на сервер с новыми параметрами для словаря, а возвращаться будет частичное представление, где будет код, подобие этого

@model  Dictionary<string, string> AdditionalFields

<script>
	var additionalFields = [];
	@foreach(var field in AdditionalFields)
	{
		@:additionalFields.push({ '@field.Key', '@field.Value' })
	}	
</script>

Судя по Вашим комментариям, могу предположить такое решение

public double TotalAmount(List<DataDevice> data)
{
	double sum = 0;;
	for(var i = 1; i < data.Count; data++)
	{
		sum  += (data[i].Indication[0] - data[i-1].Indication[0]) * data[i].Price[0] + (data[i].Indication[1] - data[i-1].Indication[1]) * data[i].Price[1];
		tempValue.Add(sumItem);
	}
	return sum;
}

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

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

Мы как раз с таким и столкнулись и сейчас проект потихоньку переводим на vue. Я не могу сказать, что он идеален. Действительно сложные вещи он делает простыми, например, где нужна реактивность, где на jq пришлось бы писать простыни кода, потеряться и потратить кучу времени на дебаг. Но простые вещи, где на jq можно обойтись тремя строками кода, он делает каким то лабиринтом из пропертей, которые надо передавать из компонента в компонент и еще прокидывать emit.

В общем мое мнение, если Вам не нужна реактивность, пользуйтесь jq. Даже если нужно переиспользование компонентов, это можно почти адекватно сделать виджетами на jq. Но если проект будет расти и он собирается жить долго, то лучше сразу делать модульно, компонентами и с использованием какого то фронт фреймворка.

Никак. В одном потоке вы его два раза не запустите. Все UI формы, работают в одном потоке.
Почему Вы не хотите отслеживать движение мыши стандартными сообщениями windowsforms?
Если так сильно хотите запустить SetHook, то запускайте его до Application.Run в main, а управление отслеживанием делайте внутри этого хука по значению булевского флага, который будете уже изменять в start().

Он не может быть рабочим, если есть такие ошибки. По видимому не подключены библиотеки или не указаны ссылки на проект, или не указаны пространства имен.

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

Паттерн от алгоритма отличается так же, как проект дома от пошагового процесса его постройки.

nanoScrollerJS