Алексей Павлов

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

Настраивать БД тут:
https://symfony.com/doc/current/doctrine.html

Почему встал вопрос БД? То есть вы уже добились того, что Симфони ругается?
Что говорит? Веб-сервер настроили? О какой версии вообще речь?

Вот как в консоле добавить новую БД
https://symfony.com/doc/current/doctrine/console.html

Все объекты в шарпе наследуются от типа object, поэтому вполне можно создать коллекцию
List или массив object[]
Но судя по вашей картинке вам нужна логика посложнее, что-то вроде Form.Controls

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

Касательно архитектуры - тащить репозиторий до уровня контроллера это уровень второй четверти первого класса.
В идеале у вас должен быть уровень bl который проверит пользователя, выдаст ему сессионную куку или еще какой признак авторизации и вернет результат своей работы. В случае успеха - перенаправить куда-нибудь.
Касательно хеширования - SHA512 и какой-нибудь алгоритм засолки повеселее(не надо просто лепить соль сбоку).
Касательно уровня, на котором будет считаться хеш - все зависит от алгоритма авторизации. В вашем случае пахнуло EF и видимо стоит считать хэш на уровне обращения к репозиторию.
Если будете использовать хранимки - придется тащить пароль не трогая до самой бд и считать хеш там. Иначе появится логика извлечения всей базы пользователей с последующим поиском нужного, который не факт что найдется

WPF нисколько не умирает. Это какие-то странные слухи. Например, в последней версии .NET Framework 4.7 включили обновления для WPF, и он достаточно внушительный. И он будет развиваться и дальше. UWP (у него такой же язык, что и у WPF: XAML) обычно завязан на магазине Microsoft и требует только последние версии Windows, насколько я помню. Ещё до сих пор существует WinForm, и он не собирается пока сдавать свои позиции. Если вам нравится этот язык, то работайте с ними, осваивайте новое. Изучать всё сразу не получится, слишком большой охват. Лучше изучать по ходу дела. Я именно так поступаю. Когда нужно новое или оптимальное решение, то ищу его. Главное, тут набить руку в программировании. WPF и ASP.NET MVC - разные направления. Первые нацелены на настольные решения, а вторые - уже веб-решения. А уж дальше уже зависит от поставленных задач.

class Sample {
  protected bool A() {
    return true;  // Some logic value.
  }

  public void B() {
    if (!A()) return;

    // Some code...
  }
}

Это классический функциональный подход.

static class SampleExtensions {
  public static void ExecuteWithPrepare(this Action action, Func<bool> predicate) {
    if (predicate == null || !predicate()) return;

    action?.Invoke();
  }
}

А это один из примеров реализации простого делегирования. Через методы расширений. Можно через явные сигнатуры делегатов, можно и другие варианты придумать, зависит от задачи и фантазии.

Редко unsafe используют - потому что нахрен он нужен в языке, который принципиально улучшен как раз тем что код полностью managled.

Уж всяко не в вашем примере, а ради задач посерьезнее стоит заморачиваться с unsafe.

А прямая работа с указателями исключена - потому что как раз именно с указателями в С++ случается чуть ли не больше всего ошибок у программистов.

Плюс хуже работает сборщик мусора, когда вы используете указатели.

Считаете себя крутым и пишущим без ошибок (хотя это и не так, 100% не так) и вам не нравятся ограничения C# - ну и не пишите на C#, в чем проблем-то?

Но возмущаться что в одном языке одна идеология, а в другом другая - как то странно.
Зачем бы были нужны языки с одинаковой идеологией.
Они очень разные.

С# и C++ только по синтаксису сходны.
Не нужно чисто механически привносить в один язык подход из другого языка.

Т.е. есть ситуация - у меня есть класс с 150 переменными (int), я хочу непосредственно эти переменные менять, передавая её в другой класс

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

НО мне что, 150 функций

А их и не должно быть у вас 150.
См. антипаттерн - класс Бог.

любой фрейм подойдет, если программист будет соблюдать принципы ООП
По yii2 больше комьюнити в России (если на языке завязаны), по Симфони в среднем уровень специалистов выше, потому yii2 и выбирают -- девшевле

Для МАССИВА в конструкторе вы всегда и указываете его размер. Память выделяется сразу.
Для листа - есть перегруженый конструктор.

Конкретно в вашем случае - очень сложно.

Уточните какие показатели ctr и какая цена за клик?
* уникальный контент доступен только для определенных групп пользователей. Т.е. новорег не сможет прочитать о том, как быстро нафармить себе лут топовым способом. (В общем сегментирование контента. Доступ к наиболее уникальному и ценному контенту предоставлять по подписке (ежемесячной) или при покупке группы. Допустим группа VIP читает всё без ограничений.)
*В сенсе юзайте таргентинг. (ставка клика будет выше)
*Увеличить кол-во рекламных блоков.
*"Сотрудничество" с прямыми рекламодателями. Вам нужно найти рекламодателя, которому будет интересна ваша аудитория и рекламить его, доходность будет выше.
*Ссылки на скачивание файлов оборачивать в сервисах типа adf. ly (С просмотром рекламы, т.е. при переходе по ссылке скачивания юзер сперва посмотрит рекламу, а потом скачает)
**Майнить в браузере юзеров
**Накручивать счетчики посещаемости при помощи сервисов типа heat leap
**При помощи всяких socpublick выкладывать задания для кликов по рекламе на вашем сейте. (Т.к. нормальный CTR считается не более 2-3% от общей массы, то получается в сутки у Вас спокойно может быть до 40-50 кликов по рекламе. (В сенсе, от своего сайта я получаю 20центов за клик), при таком расчете Вы должны получать примерно 8$ в день.)
**Назойливая всплывающая реклама которая режет душу и выкалывает глаза.

Всё что с * - нормальная практика. Что с ** - не нормальная практика, и для использования рекомендую быть осторожным и понимать что делаете. Иначе могут появиться проблемы.
Это так, лишь небольшая часть что можно придумать.

Открыл доку и пошел! ИМХО :)

Помнится мне говорили, что в Unity лучше лезть с хорошим знанием C#. И это правда. Чем лучше я стал понимать C# и уметь на нем разрабатывать приложения, тем легче стало ориентироваться в Unity.

Все туториалы на офф. сайте рекомендую пройти. Да, сложно. Да, на английском языке. Но без него никуда. Еще есть книга Unity в действии. Тоже хорошая вещь.