Ev Gen

есть, но они не нужны
https://habr.com/ru/post/444022/
можешь посмотреть
https://github.com/AmundsenJunior/rest-go-mux-pq

Из простого, но не бесплатного.
1. Берете самый дешевый VPS.
2. На железке делаете autossh до VPS
3. На клиенте подключаетесь или к определенному внешнему порту VPS или просто заходите в систему и подключаетесь к локальному порту по ssh
4. Пользуетесь железкой

Гуглите Обратный ssh тунель


P.S. вчитался в вопрос. Вам не нужен VPS, достаточно обратного туннеля до вашего сервера. На сервере будете подключаться через localhost

Несмотря на то, что эти инструменты созданы для решения одних и тех же проблем, делают они это по-разному, как под капотом, так и в плане предлагаемых абстракций. Потому нельзя сказать что async/await в C# - это "просто обертка над горутинами".

Горутины в Go - это концепция stackful coroutines (под капотом) + CSP (в абстракциях). Каждый раз, когда мы создаём горутину, под неё выделяется отдельный стек вызовов для её собственных нужд. При этом, когда происходит паника, то stack unwinding (размотка стека вызовов) происходит только в пределах этой горутины и не покидает границ её стека. Стек горутины полностью отвязан от стека её создания/вызова, потому горутина не может возвращать результат. Любое общение между горутинами выполняется либо посредством каналов, либо какой-то общей памяти.

async/await в C# (то есть, Task'и) - это концепция stackless coroutines (под капотом) + futures (в абстракциях). Код с async/await'ами компилятор превращает в определенную стэйт-машину с yield point'ами. У них нет отдельного стека, они выполняются в том же стеке что и вызывающий их код. Соотвественно, есть возможность словить exception'ы (аналог panic'и) возникающие внутри асинхронного Task'а прямо в запускающем его коде. Так как выполнение идёт на том же стеке - Task нормально может возвращать результат и мы его можем считать в вызывающем коде без дополнительных примитивов/инструментов.

При этом, если мы запустим Go с GOMAXPROCS=1, то мы получим однопоточный асинхронный код в Go (по умолчанию он многопоточный). Также и в C# мы можем выполнять Task'и как на одном потоке, так и на thread pool, получая аналогичные Go гарантии рантайма.

С точки зрения абстракций/использования - это уже вкусовщина. Кому как больше нравится. У futures лучше дизайн в плане composability (их эргономичнее join'ить и select'ить), но они вынуждают писать везде async и await. У горутин надо постоянно городить чехарду с синхронизацией (попробуйте сделать аналог await для произвольной горутины), но если эту чехарду прятать под капот (как обычно и делают), то код вообще выглядит полностью синхронным и программисты радуются.

Несколько банальных принципов ООП (применительно к вашему проекту):
Сущности, которых касается определенный запрос, должны быть либо унаследованы от одного класса, либо реализовывать один интерфейс (в дополнение к другим интерфейсам), который имеет методы управления этими сущностными, необходимые для реализации этого запроса.
Запросы также должны быть сгруппированы в дерево классов или наследовать набор интерфейсов. Сущности могут взаимодействовать не с конкретными классами запросов, а с общими интерфейсами, которых не так много, как различных запросов.
То же самое с realtime обработчиками и, вообще, с любыми элементами логики.

Знать о себе и своем поведении должна сущность.
Ибо методы доступа могут быть разные и базу Вы можете мигрировать

Приветствую.
LogManager.GetCurrentClassLogger()
Использовать следует тогда, когда вы хотите использовать отдельный логгер для каждого класса и имя логгера будет совпадать с именем класса.
Пример правильного использования:

namespace MyNamespace
{
  public class MyClass
  {
    private static Logger logger = LogManager.GetCurrentClassLogger();
  }
}

Далее всегда используете в своем классе для логирования logger.
Подробнее тут: https://github.com/NLog/NLog/wiki/Tutorial#creatin...

Если вы хотите сделать общий класс логирования и везде его использовать, то сделайте статический класс Logger, в нем реализуйте нужные вам методы логирования, которые будут использовать NLog. Т.е. примерно так:

namespace MyNamespace
{
  public static class MyClass
  {
    private static Logger logger = LogManager.GetLogger("MyCoolLogger");//или упомянутый GetCurrentClassLogger()

   public static void Debug(string message){
      logger.Log(message);
   }
...
  }
}

Собственно так используете:
Logger.Debug("Hello!");
Это простое решение, но я бы не советовал его использовать.

Я бы советовал использовать отдельный логгер для каждого класса, это BestPractise. Это позволит вам проще ориентироваться в логах, т.к. каждый логгер будет указывать на свой класс.

GLeBaTi посмотрите:
Smart Install Maker
Excelsior Installer
InstallBuilder 9
advanced installer
InstallSimple

Будет. Ссылка идёт не на поле объекта, а на объект, который когда-то лежал в этом поле. После чистки останется только объект d. Вот если бы в d при конструировании была ссылка на b, как на "родителя", то b бы тоже остался.