Илья Голец

Я бы тут ещё попробовал ответить на следующие вопросы:

1. Какие требования к срокам выпуска приложения?
   
2. Как часто будет меняться приложение?
   
3. Какой перечень клиентского оборудования и операционных систем? Будут ли это планшеты на iOs, например. Если только ноуты с одинаковой операционкой — то почему?
   
4. Какая интеграция с десктопом потребуется? Например, запуск в режиме киоска (без элементов операционной системы), горячие клавиши, локальная БД, интенсивные вычисления, лимиты памяти, нестандартные элементы управления (джойстики и т.п.), внешние динамики/мигалки/дисплеи, контроль активности пользователя.
   
5. Много ли экранных форм и насколько они разнообразны?
   
6. Какой опыт у разработчи(ка/ков)
   

Суть в том, что для работы с оборудованием, например, комфортнее десктоп (хотя и с веб это возможно). Для некоторых типов приложений мне, например, быстрее также использовать десктоп, потому что есть библиотеки, с которыми я могу простое готовое приложение сделать за часы (с валидацией и т.п.). С юнит-тестами в той среде, в которой с работаю (.Net) проще с десктопным кодом, чем с JS. Но веб, по понятным причинам, убирает многие границы (разные операционки, доставка приложения и т.п.). Опять же веб подразумевает серверную часть. В ряде случаев это подразумевает два языка программирования, две валидации ввода, две обработки ошибок.

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

Удачи!

Это нужно погуглить по ключевым словам "entity framework many to many fluent".

// к User добавить 
        // Subscribers
        public ICollection<UserSubscriptions> Subscribers { get; set; }

// при конфигурировании датаконтекста использовать следующий fluent синтаксис
modelBuilder.Entity<User>()
   .HasMany(u => u.Subscriptions)
   .WithMany(u => u.Subscribers)
   .Map(cs =>
   {
       cs.MapLeftKey("UserId");
       cs.MapRightKey("SubsUserId");
       cs.ToTable("UserSubscriptions");
   });

Тут важный вопрос. Общие части системы можно редактировать, или нет?

Если нет — можно вынести их в отдельные репы, собирать из них nuget модули и публиковать в частном nuget репозитории.

Если нужно редактировать и хочется заморочиться, то можно сделать следующее:

1. Сделать репозитории для небольших подсистем
   
2. Для каждого проекта сделать по репозиторию, составить список подсистем, которые в нём используются и
   
3. В репозиторий проекта добавить подсистемы через https://git-scm.com/book/en/v2/Git-Tools-Submodules
   
4. Добавить код, уникальный для проекта в виде отдельных папок в репозитории проекта.
   
5. Постараться не запутаться во всём этом великолепии и не сломать друг другу работу.
   

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

1. Да, в iOs есть такая функция, но её можно отключить для своей сети WiFi. В свойствах сети можно снять галочку "Частный адрес WiFi".
2. У меня как минимум на двух маршрутизаторах после подключения макадрес не меняется и whitelist прекрасно работает и без отключения этой галки.
3. Из обходных решений — на iOs есть "Команды", там можно настроить автоматический макрос, который будет срабатывать при подключении к домашней WiFi сети, можно создать автоматизацию, которая будет что-то дергать в системе умного дома. Логика получится немного размазанной, но с высокой гарантией.

Полагаю, что на Андроид тоже должно что-то похожее быть.

Плагин whitelist пробовали?

Если есть задача запуска чего-то на настольном компе, то можно попробовать извернуться следующим образом:

1. На C# написать прикладное ПО, которое взаимодействует с пользователем/БД/(нужное дописать)
   
2. Через (например) USB/Serial port подключить плату с микроконтроллером
   
3. На микроконтроллере (у него частота известна) запустить программу, которая, манипулируя NOPами, обеспечивает необходимые задержки. Точность, очевидно, будет очень высокая — половина такта процессора микроконтроллера (с учетом погрешности тактового генератора)
   
4. Приложение на C# в нужные моменты посылает сигнал плате с микроконтроллером.
   

В этом случае будут неизбежные задержки отправки сигнала плате из приложения на C# (по причинам, указанным выше), но сама плата будет выдавать гарантированную частоту. Человек задержки на стороне C# не заметит, а оборудование, которому шлёт сигналы микроконтроллер, будет получать комфортную частоту сигнала.

Плату с микроконтроллером можно заменить на что-то, на чём запущена Realtime OS. Суть не сильно поменяется.

1. Хорошо бы иметь базовое образование — знать, что такое алгоритмы и структуры данных. Знание другого языка программирования подойдет.
   
2. На счёт книг — они по определению не бесплатны, кто-то вложил в них труд. Бесплатно — это либо читать документацию на сайте Microsoft, либо брать книгу у друзей/работодателя, или скачать украденное. Тут я рекламировать не буду, в принципе, для знакомства подойдет любая книга. Ещё есть ресурс https://docs.microsoft.com/ru-ru/learn/ (подробнее на https://habr.com/ru/company/microsoft/blog/426919/)
   
3. Дальше нужно определиться с направлением работы (для чего нужен C#). Это может быть десктоп программирование, или веб, Azure и т.д. Тут могут потребоваться более специфичная литература. Я бы порекомендовал зайти на сайт https://docs.microsoft.com/en-us/certifications/browse/, выбрать интересующие направления и поискать (хотя бы и украденные) книжки по выбранным экзаменам, или MS Learn. Я как-то через сертификацию проходил, её преимущество в том, что дается довольно целостный и полный объем знаний. В том числе придется освоить темы, которые обычно пропускаешь, но которые могут быть важны для профессиональной разработки. Например, вопросы безопасности.
   

На счёт «как эта область называется, и в какую сторону копать» — наиболее близкие по смыслу — это «Service oriented architecture» и «Event driven architecture». Подробно раскрывать не буду, почитайте на досуге.

Очереди сообщений (те самые MQ из RabbitMQ) тут как раз могут быть полезны и будут помогать с масштабированием. В идеале, чтобы избежать ненужных ожиданий, хорошо бы разрешить внешним серверам работать с очередями (как минимум, писать в них задачи на обработку).

Касательно масштабирования — не очень понятно, какую часть вы пытаетесь масштабировать. Мое предположение — скорее скрытые сервера, которые, как я понял, делают какую-то нагруженную обработку. При наличии очереди сообщений вы можете делать произвольное количество серверов, которые вынимают задачу из очереди, обрабатывают и помечают задание как выполненное. Более того, если разворачивать решение на облачной платформе (любой), можно создать метрику, которая анализирует длину этой очереди и при её росте автоматически запускает новые инстансы (сервера) в «скрытой» зоне. А при уменьшении очереди так же автоматически их тушит, чтобы не тратить деньги.

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

А если говорить о том, как делаются «промышленные» (не самопальные) системы такого рода, то тут будут следующие слои начиная от пользователя:

1. Балансировщик нагрузки
   
2. Веб-приложения (их может быть несколько, чтобы можно было, например, по одному отключать и обслуживать)
   
3. Очередь сообщений
   
4. База данных
   
5. Сервера фоновой обработки
   

Веб-приложения могут добавляться в пул по метрикам загрузки процессора и времени ответа.
Сервера фоновой обработки могут добавляться в пул по метрикам длины очереди.

1. Deel
   
2. Тут, вроде, точка недавно опубликовала инфу, что они сделали промокашку для UpWork
   

Как я обычно с таким борюсь.

1. Сделать (или взять у поставщика XML данных) файл со схемой XSD

2. Из XSD сделать файл C# командами:

xsd SourceFormat.xsd /c /n:NameSpace /o:tmp
cd tmp
ren SourceFormat.cs     SourceFormat.designer.cs
move /y SourceFormat.designer.cs ..
cd ..
rd /s/q tmp

(кратко что тут происходит — создается .cs файл в каталоге tmp, чтобы при ошибках не затереть исходник, потом .cs переименовываем в .designer.cs и помещаем в основной каталог)

3. Оба файла (xsd и .designer.cs) можно добавить в проект, красиво отобразить второй как вложенный в первый

4. Использовать упомянутый XmlSerializer для записи

var serializer = new XmlSerializer ( typeof ( nmaprun ) );
                using ( var writer = new StreamWriter ( xmlFileName ) ) )
                {
                    serializer.Serialize ( writer, item );
                    writer.Close ();
                }

и для чтения

using ( var temp = new StringReader ( xmlText ) )
                    {
                        var tmp = serializer.Deserialize ( temp );
                        return ( nmaprun ) tmp;
                    }

Привет. По-хорошему, лучше сделать два проекта, запустить их в параллели и каким-то образом (через модный MessageBus, или каким-нибудь RESTful запросом) дергать второй процесс из первого.

Но если очень хочется влоб, то могу посоветовать разве что покопать вот эту штуку: https://docs.microsoft.com/ru-ru/dotnet/api/system...
Ещё важно будет учесть, что тут загружаемая ассембли грузится в домен приложения. Если в этом домене уже загружена та же ассембли другой версии могут быть накладки. Поэтому хорошо бы ещё поизучать тему доменов, вот тут, например https://docs.microsoft.com/ru-ru/dotnet/framework/...
Я сам тему предметно не копал, изучал только в ходе подготовки к экзамену, но как я это понял, суть будет почти та же, что и первый вариант — по сути, из основного кода запускается второй поток в другом домене. Разница только в том, что можно попробовать сделать одно приложение, которое в себе содержит второе и умеет его запускать.

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

1. Хорошо бы код, который работает с оборудованием (читает данные) вынести в отдельный класс и сделать под него интерфейс. Для чего нужно — если нужно будет разделить работу "железячника" и программиста интерфейса, второму можно будет дать возможность запускать программу с "заглушкой", чтобы он пилил интерфейс без доступа к железу. Ну, или для демонстрации программы запустить без доступа к железу.
   
2. Соответственно, По событию на форме (старт/стоп) вызываются некие методы класса работы с железом и происходит получение/накопление данных. В зависимости от логики этого класса вызываются события (по получении байта, или полного пакета)
   
3. По событию (код формы навесил обработчики событий при инициализации кода, работающего с железом) форма уже обращается к экземпляру класса, который работает с железом и получает от него данные (скорее всего, в сыром бинарном виде) и что-то с ними делает. Например, преобразует в класс-модельку, которая добавляется в биндингсорс (List), который используется как DataSource для ListView
   
4. Код трансляции бинарных данных в модельку лучше тоже в отдельный класс вынести. Могу предположить, что могут быть разные формы представления данных.
   

Вкратце так.

Ну, а код класса имитации будет имитировать работу настоящего класса, вызывать нужные события и отдавать заранее записанные данные, или генерить по какому-то алгоритму. Переключение между заглушкой и настоящим классом реализуется, например, при помощи Dependency Injection, для C# можно использовать что-то типа https://habr.com/ru/post/50845/. В конфиг-файле прописывается, какой класс используется и всё, один и тот же код в рантайме использует разные классы. Лично я, например, так реализую работу с Фискальными аппаратами и терминалами оплаты пластиковыми картами.

Недавно Яндекс выкатил интересное демо своей технологии TTS (https://yandex.ru/promo/browser/video_translation/m/03), мне озвучка очень понравилась. Планирую в отпуске поиграться, попробовать озвучивать книги.

Для .Net я бы посоветовал OWIN — https://docs.microsoft.com/en-us/aspnet/core/funda...

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

Кстати, ASP.NET шаблоны сейчас активно используют owin.

В диалоге паблиша на вкладке Settings указать "Target runtime = Portable" - не оно?