eRKa

Как вариант библиотечка lodash

JSON, это описание объектов в JavaScript. И поле response это не массив, а объект с полями "AK-47 | A...", соответственно и эти поля тоже не массивы.

Вариант первый, некрасивый и похож на хак, это заменить {} у респонса на [], тогда он станет массивом, ну и в остальных нужных местах и можно будет десериализовать к dictionary.

Вариант второй, трансформировать этот Json к другому типу Json. Тут сложнее, потому что нормальных библиотек для этого просто нет. Когда мне это надо было делать, я использовал JUST.net. Что мне в ней понравилось, так это быстрый фидбек от разработчика, если не хватает функционала, то он очень быстро его по Вашему желанию добавит. Ну а после трансформации, десериализуйте его уже во что захотите.

P.S. Тут в процессе диалога с Stalker_RED, еще один вариант созрел. Если Вы уверены в структуре Json объекта, то его можно привести к JObject. Этот объект представляет собой дерево, где Вы сможете взять узлы (поля) первого уровня, у них получить узлы второго уровня, соответственно из каждого из узлов получите имя и значение. Ну так и сформируете свою модель, какую захотите. В Вашем варианте это будет оптимальным решением.

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

switch(functionName){
    case 'func2': func2(); break;
    case 'func3': func3(); break;
}

Вынесите только его в отдельный метод.

Если решили делать spa, то я бы не советовал смешивать фронт с asp частью. Лучше вынести всю фронтовую часть в отдельный проект, а собранный index уже отдавать asp проектом и его же использовать просто как web api. Тогда ничего мешаться не будет.

Пользуюсь vs2017 на i7, ssd, 8Гб. Каких-то особых проблем не испытываю. Но по сравнению с vs2015 она конечно глючнее, бывает подвисает у меня, приходится через менеджер закрывать и перезапускать. С vs2015 вообще никогда проблем не испытывал.
А вообще студия нормально кастомизируется. Можно отключить многие вещи, которые не используешь в работе. Например профайлер, он не плохо так ресурсы ест.

У Вас здесь несколько ошибок.

Во первых, Вы в сигнатуре метода Run()указали, что он возвращает объект типа Task, но return не сделали. Если Вы хотите, чтобы он возвращал таску, то ее надо создать

var task = new Task(() => async
{ 
	Console.WriteLine("Hello from begining \"Run\" method");
    int num = 1000000000;
    long res = await new TaskFactory().StartNew(() => { return SumZeroToNum(num); });
    Console.WriteLine($"Result: {res}");
});

а потом вернуть
return task;

Но сделав в методе Main Run(), Вы только получите объет задачи, автоматом он у Вас не выполнится. Для этого Вам нужно будет сделать t.Start();
Если хотите, чтоб вызывать метод можно было через async, то внутри надо сделать так

return Task.Run(() =>
{
    ....
})

Тогда запустить его можно будет асинхронно
await Run();
Или синхронно
Run().Result;

Не совсем понятен вопрос. Сохранить отдельным решением?

Создайте новый солюшен.
Зайдите в каталог солюшена от куда надо вытащить проект.
Найдите папку с проектом, скопируйте ее в каталог нового солюшена.
Из студии правой кнопкой по новому солюшену, добавить проект -> существующий.
Из старого солюшена удаляете скопированный проект.

Есть такое дело, что не рекомендуют показывать реальные id на клиенте. В этом случает заводят еще одно поле, чаще всего guid, и если на клиенте нужно показать какой то идентификатор, то показывают его.

Все эти DI, IoC придумали для слабой связанности. Т.е. их использование оправдано, если Вы хотите разорвать сильную зависимость между какими-то модулями или объектами, т.к. в будущем ожидаете изменений или хотите добавить возможность тестирования какого-то участка кода.

Если Вам не принципиально ни то, ни другое, то не стоит доводить до фанатизма)

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

Когда Вам нужно что-то записать, обычно берут листочек и ручку. А можно не ручку, можно карандаш, можно фломастер или перьевую ручку. Полиморфизм будет заключаться в том, что Вам нужен объект, которым можно что-то записать, а какой конкретно и как он реализует саму запись Вас не сильно беспокоит. Т.е. когда Вы скажите: "дай мне объект для записи", Вам можно будет подсунуть любой объект, который как абстракция будет является "перо".

Когда Вы хотите спать, Вы говорите: "дай мне на что можно лечь". И можно будет лечь хоть на диван, хоть на кровать, хоть на кресло-кровать. Абстрактно это все будет "кровать", но реализацию будет иметь разную.

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

Любой заказчик хочет чтоб было быстро и дешево. И если он решил сделать сайт на wix, то будет искать того, кто ему это сделает, а не того, кто будет отговаривать. Значит он определился, что решение на этом конструкторе сможет решать его бизнес-задачи.

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

Если же это просто Ваш вкус и нелюбовь к wix, то вы можете потерять заказчика.