Maa-Kut

А где нужно, "по уму", закладывать проверки, что в числовое поле введено число? Где фильтруются sql-инъекции, HTML-разметку и прочие грязные хаки?

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

Как распределена ответственность между частями системы в рамках архитектуры MVC в случае с толстым клиентом?

Толстый JS-клиент можно сам по себе рассматривать как MV*-приложение. Серверная часть в этом случае становится моделью. При этом часть функций модели (скажем, некая базовая валидация) может быть реализована и на стороне JS; в конце концов, никто не говорит, что модель не может состоять из нескольких слоев.

В первую очередь: для корректной работы с хэш-коллекциями (типа Dictionary), а именно - при использовании в качестве ключа. Их внутренняя логика предполагает, что если для двух объектов Equals возвращает true, то и значения, возвращаемые GetHashCode, должны быть равны. Если это не так, то коллекция будет работать некорректно: скажем, не находить значения по ключу, хотя они там есть.

Как вариант - ASP.NET Web API. Под Mono, вроде бы, работает.

Работа работе рознь. Существует бесплатная Community Edition, которая содержит почти все необходимое (во всяком случае, лично я пока не натыкался на отсутствие каких-то реально нужных фич). Есть ограничения на коммерческое использование, но одиночного разработчика они не затрагивают.

Что до ReSharper'а, то очень многие отлично и без него живут, благо в VS хватает функционала "из коробки". Я сам ставил его когда-то, поигрался немного и удалил: не впечатлило.

Во-первых, .NET тоже потихоньку осваивает Linux.

Во-вторых, госсектор не является единственным или основным заказчиком .NET-решений. А уж к Enterprise госсектор и вовсе имеет весьма опосредованное отношение.

В-третьих, означенное "пересаживание" может запросто затянуться на долгие годы: школы вон тоже на Linux перевести хотели еще лет 8 назад, и что?

Наконец, при желании легко найти лазейки. Скажем, разработанная система будет не устанавливаться в госконтору напрямую, а предоставляться некоей коммерческой организацией как сервис (по удачному совпадению эта организация будет явно или опосредованно принадлежать какому-нибудь чиновнику ;)).

Одним словом, не беспокойтесь :)

P.S. И что такого откатного в продвижении C#? Не откатнее остальных :)

Контекст во всех репозиториях один и тот же? Если так, то при ошибке сохранения сущности ее следует "отцепить" от контекста:
db.Entity(item).State = EntityState.Detached;
По идее, контекст после этого сущность отслеживать перестанет и уже не будет пытаться ее в базу пропихнуть.

Очень смахивает на проблему неправильного использования замыканий. Попробуйте так:

for (int i = 0; i < qEquations; i++)
{
    int index = i;
    system.EquationFunctions.Add(new Func<double[], double[], double>((x, beta) =>
        EquationFunction(x, beta, index)); // <-- index вместо i
}

Если я правильно понял задумку (без HTML не совсем понятно), то, наверное, как-то так:

$('.value').each(function() {
    var val = parseInt($(this).text());
    if (val >= curVal)
        $(this).css('color', 'red');
});

Как вариант, можно использовать MemoryCache: stackoverflow.com/questions/7435832/c-sharp-list-w...

Советую задаться вопросом: у вас настолько много текстовой обработки и она настолько сильно тормозит? Дело в том, что вызов чего-либо exec'ом и или через предложенный тов. evnuh ZeroMQ - штука отнюдь не бесплатная. Есть серьезный риск, что накладные расходы на обращения к внешним программам перекроют все выгоды.

Иными словами, если у вас там просто накапливается большой пул строк, которые можно одним пакетом передать на внешнюю обработку - есть смысл париться. А вот если ваша цель - заменить кучу разбросанных по коду preg_match'ей (или что там в пыхе) на свою функцию, "ускоренную" Go или Python'ом, то не советую.

Зачем вообще делать что-то свое, если уже есть что-то готовое? Вариантов вижу три:

1. NIH-синдром. Разработчик чисто из принципа старается использовать только то, что сам создал, минимально привлекая сторонние разработки/инструменты. Логику тут искать, как правило, бессмысленно.

2. "Свое" решение появилось раньше другого готового. В мире существует немало игровых движков, созданных еще до Unity. Собственная разработка уже давно используется, она отлажена и проверена временем, под нее много всего понаделано; выкидывать ее на помойку ради какого-то новомодного Unity откровенно жалко.

3. Готовое решение не отвечает всем требованиям. Скажем, для какой-то конкретной игрушки Unity слишком тяжелый, или же не поддерживает каких-то очень нужных фич, или поддерживает, но недостаточно хорошо (ресурсов слишком много жрет). "Свой" движок под конкретную игру может быть заточен лучше, что автоматом даст конкурентное преимущество перед другими играми, сделанными на Unity.

Да просто докидывать их к IQueryable:

IQueryable<Person> query = context.Persons;

if (searchByFirstName)
    query = query.Where(x => x.FirstName == someFirstName);

if (searchByAge)
    query = query.Where(x => x.Age == someAge);

var persons = query.ToList();

При генерации SQL-запроса все эти отдельные условия соберутся в один красивый WHERE.

Другой вариант: собирать Linq Expression'ы. Способ более гибкий, но более сложный. Почитать, скажем, можно тут: https://msdn.microsoft.com/en-us/library/mt654267.aspx.

$('<div/>', { ... }).insertAfter("ul.map-visible-list").data('toggle', 'modal').data('target', "#modal-map-body");

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

Альтернативный вариант: он ведь на какой-то хостинг сайт для демонстрации выкладывает? Если у вас есть к нему (хостингу) доступ, то можно все утащить оттуда.