Евгений

Если в двух словах, то ввести дополнительный слой абстракции - шину. Клиент делает запрос к шине, которая в свою очередь опрашивает инстансы доступных WCF-сервисов. Пока инстанс WCF1 обновляется, шина перенаправляет запрос на резервный WCF2. После деплоя обновления на WCF1 - переключаемся уже на обновленный сервис.

Для лога можно использовать паттерн Memento: https://en.wikipedia.org/wiki/Memento_pattern

1. попробовать в плюсы
2. высоконагруженный проект, микросервисы, докер; одновременно можно и сменить платформу на java
3. поботать f#...ну а что, вставляет хорошо после ООП и C#: https://fsharpforfunandprofit.com/
3.1 там же можно и аналитику данных пощупать: https://fslab.org/

Нужно быть осторожным при их копировании.

В твоём случае, в поле myClass хранится ссылка на область памяти в куче. При копировании value type( к чему относится struct) создаётся просто новое значение на стеке.

var a = 0;
var b = a; //на стек помещается значение 0. Число есть число, ни на что не ссылается

В копии структуры ссылочное поле инициализируется копией ссылки(а она ведет к тому же объекту на кучу) которая помещается на стек. Иными словами ты получишь поверхностную или shallow копию. При изменении свойств объекта ссылочного типа в одной структуре ты увидишь те же изменения и в поле копии.

Включить пакет SqlClient в файл project.json.

{
    "dependencies": {
       ...//здесь идут ваши зависимости
        "System.Data.SqlClient": "4.1.0-*"//это нужно добавить
       ...
    }
  }
}

Сохранить изменения в файле. Подождать пока References проекта переопределятся.

Затем все как обычно:

using (SqlConnection connection = new SqlConnection(connectionString))
{
           connection.Open();
           using (SqlCommand command = new SqlCommand("SELECT * FROM dbo.Table", connection))
           {
                  var reader = command.ExecuteReader();
                  while(reader.Read())
                  {
                        var a = reader["Column"];//инициализация значения переменной полем из таблицы БД
                  }
           }
}

Примечание:

connectionString = "Data Source=ServerName;Initial Catalog=DatabaseName;Persist Security Info=True;User ID=UserName;Password=Password;"))

Думаю, навык рефакторинга приходит естественным путем с тренировкой навыка написания грамотного кода. Все, что остается делать - познавать правила, и писать качественный код. Как только после этого Вам откроют проект с "плохим" кодом - сразу "зачешутся" руки: тут дублирование кода, здесь длинный метод, а вот здесь еще и слишком много ненужных локальных переменных...

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

Для начала я бы определисля с нагрузкой. Как часто пишутся данные, каким образом их нужно выбирать. Для большинства случаев, более оправдано использовать ORM. Еще лучше, использовать одну из популярных ORM(EF, NHibernate, etc.). Если у вас будет какой-то очень огромный проект с выдающимся количеством транзацикций по обработке данных в секунду, то здесь лучше pure SQL(или же компромисс: на сложные операции pure SQL, на шаблонные, коих в любом проекте предостаточноб ORM).

ORM(например, в случае EF, который я использую) позволит избежать большей части "monkey job":
-Запросы осуществляются к DbSet-ам(типизированными доменными моделями), что дает нам строгую типизацию => меньше ошибок.
-Cами доменные модели наполняются виртуальными свойствами на связные сущности(для реализации one-to-one, one-to-manu, many-to-many отношений), что позволяет нам избавиться от кучи Join-ов в будущем.
-Используя Linq to entity, мы можем возвращать в результате запроса нужный объект, что делает обход выборки результата проще(меньше лишних инициализаций => меньше кода => меньше возможных ошибок и багов).

В общем, ORM экономит много времени(а, соответственно, ресурсов, нервов и т.д.). Да и никто не мешает потом использовать pure-SQL: в случае если ORM неоптимально конвертирует запрос в SQL и вы хотите его переписать. Впоследствии, все это(ORM, ADO.NET ... <любой другой источник данных>) оборачивается репозиторием - и получается у вас Dаtа Access Layer.

Upd: исправлены опечатки.