Станислав Макаров

По ссылке что вы привели упоминается ProtectedConfigurationProvider, который находится в неймспейсе System.Configuration и вроде как прямого отношения к ASP.NET не имеет. Вы уверены что нельзя его использовать в вашем случае?

> Объект, работающий с SerialPort находится в отдельном потоке?

Цитирую из https://msdn.microsoft.com/en-us/library/system.io... :

The DataReceived event is raised on a secondary thread when data is received from the SerialPort object. Because this event is raised on a secondary thread, and not the main thread, attempting to modify some elements in the main thread, such as UI elements, could raise a threading exception. If it is necessary to modify elements in the main Form or Control, post change requests back using Invoke, which will do the work on the proper thread.

А вообще, если есть еще какая-то логика обработки данных, приходящих из порта, то лучше вызывать ее в ивенте DataReceived, и уже в ней, после необходимой обработки, отправлять более высокоуровневые сообщения в GUI-поток через какую-нибудь очередь сообщений, например организованную с помощью ConcurrentQueue. Тогда ваш GUI-поток будет дергаться не по приходу пары байт, а тогда, когда вам самим это будет нужно. Но это уже архитектурный вопрос, который я вас советую продумать, если у вас не одноразовая лаба.

Никаких lock-ов в экшене не будет (если вы их сами туда не поставите), и не нужно им там быть. Дефолтовая фабрика контроллеров создает инстанс контроллера на каждый запрос, поэтому 99 пользователей одного ждать не будут. Если нужны подробности - ищите в гугле "asp.net mvc controller instancing", вываливается масса статей с которых можно начать разбираться.

Вам надо определиться с рядом требований к вашему приложению, в частности - на каком уровне абстракции оно работает с БД. Если на метауровне - т.е. для вашей программы нет ничего кроме набора неких таблиц и вьюх в базе (иными словами у вас чтото вроде стандартного шелла для работы с базой) - то это одна ситуация, и тут вам бы работать с INFORMATION_SCHEMA (чтобы без свитчей) и действительно собирать SQL-запросы самому. Если же у вас стандартные бизнес-задачи (создать запись о клиенте, заказе, ..., сохранить, отредактировать данные), и вы конкретно знаете, что у вас за таблицы и что там хранится, то почитайте про актуальные подходы к работе с данными в базах с использованием ORM, в случае дотнета - Entity Framework и NHibernate.

Если я правильно понял проблему, то вам надо работать с вашим предикатом, как со значением. Иными словами, работать с функцией, возвращающей bool, как с first-class объектом. Для этого в С++ есть std::function. Он позволит вам обернуть ваши проверки в функтор, и их можно будет поместить в очередь/список и т.д. Еще вам наверняка поддержка лямбда-функций в С++11.

Из структур данных попробуйте посмотреть вот это (если конечно вам нужен поиск подстроки, а не всей строки целиком): https://ru.wikipedia.org/wiki/%D0%A1%D1%83%D1%84%D... , там есть ссылки на известные труды, что касается "не загружать оперативную память" - в общем-то для любой структуры данных можно организовать гибридное хранение - сам индекс построить заранее и хранить на диске (вполне логичный ход в случае предварительно подготовленного словаря), а в память загружать части индекса. Однако это значительно усложнит алгоритмы, нужно это вам или нет - зависит от деталей поставленной задачи (объем словаря, предельное время поиска и т.д.)

Вопрос действительно академический: вам нужно основательно разобраться с событийно-управляемой (event-driven) архитектурой приложений. Пожалуй, все современные графические подсистемы так или иначе построены на ней (а вообще - не только графические). И в первую очередь нужно понять, что выполнение действий в своем цикле без передачи управления обработчикам сообщений - неверный подход. Дело в том, что GUI-приложение, в отличие от консольного, для того чтобы "не зависать", должно постоянно выполнять некоторые действия помимо нужных для вашей задачи, а именно - перерисовываться, обрабатывать события клавиатуры и мыши и т.д. Изза того что ваша программа "крутится" в цикле, то все те стандартные обработчики событий, которые должны получать управление, не получают его. Поэтому, если нужно выполнять интенсивные вычисления в графическом приложении, нужно либо:
а) выполнять их в другом потоке - тогда получится сохранить структуру приложения и циклы, но встанет задача межпоточной передачи данных;
б) выполнять работу порционно, время от времени передавая управления обработчикам системных событий. Это т.н. вызов DoEvents, в разных API он разный, но суть одна и та же.

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