Сергей

Использовать в C# Reflection можно и нужно, не спешите с "улучшением" производительности пока в этом нет необходимости. А в случае необходимости изучите результаты Profiler, я думаю упретесь в IO а не в скорость работы Reflection.

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

Использовать стоит однозначно, но благоразумно. Все сильно зависит от задачи но:
- если связанные данные точно понадобятся то можно загрузить одним запросом (см. .Include(...));
- при ленивой загрузке запрос будет _только_ при обращении к свойству, но если не воспользовались include то это в любом случае запрос;
- вероятно речь о code first, не забываем про индексы (fluent api)
- если все стало плохо то всегда можно воспользоваться видами (в том числе материализованными) или прямыми запросами

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

Мне нравиться на хабре, а затем лучше сразу на TypeScript переходить.

Думаю, что оправдано т.к. это единственный "честный" путь выгрузки сборки.

При вызове функции из другого AppDomain используется маршаллинг так, что будут потери в производительности на сериализацию/десериализацию передаваемых/возвращаемых между сборками объектов. Если передаваемых/возвращаемых данных не много тогда не критично. Затраты памяти на дополнительные GC и сами AppDomain думаю не принципиальны.

Недавно была описана альтернатива, но имхо не стоит так делать.

ЗЫ Если интересует готовый каркас приложения, обращайся.