Толстый Лорри

При каждом изменении моделей и/или их связей, нужно сначала сгенерировать очередную миграцию (Add-Migration), а затем - накатить изменения на схему (Update-Database).

В CLI будет так:

dotnet ef migrations add NewMigrationName;
dotnet ef database update;

Подробнее читать тут.

var newPerson = new People {
   //Id = model.Id,
   Name = model.Name,
   Treatment = new Treatment {
        //...
   },
};

dbCcontext.People.Add(newPerson);
dbCcontext.SaveChanges();

Конструктор SelectList имеет сигнатуру :

public SelectList (System.Collections.IEnumerable items, 
                   string dataValueField, 
                   string dataTextField,
                   object selectedValue);

Поэтому вторым параметром необходимо указать имя свойства для значений элементов option:

new SelectList(_context.Department, 
               nameof(Department.DepartmentID), 
               nameof(Department.Name), 
               person.DepartmentID);

Дело не в razor, а в том, что вы заведомо пишите невалидную разметку. Как должен браузер обрабатывать клик по внутренней ссылке? Игнорировать ее или внешнюю? Он, вероятно, что-то все же сделает, но не факт то, что вы ожидаете. А парсер разметки в Razor считает, что лучше вот так интерпретировать.

Судя по тому, что на внешней ссылке (catalog-item) нет аттрибута "href" (он обязателен), вам она нужна лишь для руки-указателя. Того же эффекта можно добиться с div:
.catalog-item:hover { cursor: pointer; }

await еще не означает создания дополнительный поток (тред). Особенно, когда дело касается асинхронного ввода-вывода.

В десктопных приложениях в основном потоке есть Главный Цикл (event loop), который в свободное от обработчиков время перемалывает очередь сообщений окна (дёргает эти самые обработчики в ответ на соответствующие события, вроде нажатия кнопок). Если обработчик попался слишком жирный, то сообщения не обрабатываются - окно перестает реагировать на сообщения.

В вебе (ASP.NET) же каждому новому запросу выделяется новый поток. Если запросы выполняются слишком медленно, а клиенты поступают и поступают, то есть риск исчерпать thread pool. Как правило, самые медленные действия - это ввод-вывод, при которых поток нашей программы ничем не занят, кроме ожидания. Но операционные системы могут делать асинхронный ввод-вывод (сигналить, когда данные были прочтены/записаны), так почему бы нам не вернуть напрасно простаивающий поток в тредпул? А когда данные считаются - мы выделим поток и вернемся к задачке.

Partial Views (и вообще средства Razor) - это серверный рендеринг, тут ни о каких щелчках по кнопкам речи не идет. Здесь решения может быть в общем случае два:

1. рендерить с display: none, а при щелчке менять стиль (JS или :checked в CSS )
   
2. рендерить на клиенте, уже фактически изменяя DOM
   

Не нужно хранить в базе ActualPerformanceTime, т.к.

1. значение будет пересчитываться при каждом новом запросе
   
2. оно должно допускать разрывы (паузы)
   

Можно каждой таске сопоставить таблицу один-ко-многим с временными отрезками:

class MyTimeSpan {
    public int Id { get; set;}
    public DateTime From { get; set; }
    public DateTime? To { get; set; }

    public int TaskId { get; set;}
    public Task Task { get; set;}
}

При старте MyTimeSpan.To остается null, при Stop или Pause - отрезок "закрывается". Если хоть один отрезок не закрыт, то таска находится в прогрессе (Task.TaskStatus не нужен. Тем более, что название свойства - тавтология).

Имеющий руки да загуглит!

public ActionResult Index()
{
    byte[] contents = GetPdfFileData();
    return File(contents, "application/pdf", "test.pdf");
}

1) Использовать файл конфигурации приложения для User-specific настроек

Рядом со сборкой (MyApplication.exe или MyApplication.dll) можно положить XML-файл настроек (MyApplication.config), который будет влиять на конкретный экземпляр сборки. Можно почитать об этом у Рихтера (в главе про разветывание сборок) или в документации, там же есть XML-схема.
Кроме того, такой Web.config файл есть у каждого ASP.NET-приложения (а у десктопного - App.config) на уровне проекта (не путать с Web.config в папке Views)

2) Использовать ресурсы для хранения UI-строк

Все видимые пользователю строковые ресурсы в приложениях принято оборачивать заменять на локализованный эквивалент. Это может быть сервис, в который подставит нужные значения, в зависимости от настроек приложения/языка пользователя и т.п. Грубо говоря, словарь терминов, который выбирает значения из таблицы по значению. Используется что-то вроде:
<h3>@Localization.Get("Contacts_PageHeader")</h3>
Извлекать значения, соответственно, из ресурсов.

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

Хотя, зачастую их вообще избегают в пользу мелких вкраплений в HTML и PartialViews. Тем более, что ASP.NET Core уже идет по классическому пути шаблонизаторов - использует специальные аттрибуты (TagHelpers).

Нужно настраивать моки. Они по умолчанию возвращают default-значение требуемого типа. Таким образом внутри AddCategory мок репозитория всегда дает result == null и, соответственно, null возвращается, тест падает.

var model = new CategoryModel { ... };

var categoryModelRepository = new Mock<ICategoryModelRepository>();

categoryModelRepository.Setup(x => x.AddCategory(model))
                                            .Returns(model);
// Или
categoryModelRepository.Setup(x => x.AddCategory( It.IsAny<CategoryModel>() ))
                                            .Returns(model);

// Act...

Assert.IsNotNull(result);

ИМХО, стоило бы изучать с Шилдта или Троелсена. Там язык подается в чистом виде, с консольными примерами, без заморочек с GUI в самом начале. XAML в вебе не нужен (ибо Silverlight, где он использовался, не особо жив), это правда.

Для ASP.NET MVC нужен HTML/CSS и базовый SQL (ORM в виде EF есть, да, но гораздо легче ею овладевать, зная, как она общается с сервером). JavaScript можно учить параллельно. С ангуляром я бы советовал повременить, вместо него jQuery (что бы хипсторы не говорили, он сейчас почти везде).

Вообще, идеально было бы распараллелить изучение C# в глубину (по Рихреру, например), баз данных и DAL (ORM - EF), ASP.NET MVC и веб-фронтенда, ибо в изоляции друг от друга сложнее.
Смотреть на ASP.NET Core новичку сейчас есть смысль лишь если нет другого компьютера, кроме мака.

На Git выделять в отдельный шаг - это слишком. Базовые операции с Git можно изучить за вечер, по необходимости дочитывать в процессе, может еще пару вечеров факультативно выделить на "internals". Вообще необходимость в нем появится, когда будешь делать первый крупный pet-проект (то есть это где-то в процессе освоения ASP.NET MVC).

не могли бы вы посоветовать книги для изучения С# имено под веб ?

Адам Фриман "ASP.NET MVC X для профессионалов"
В продаже есть версия про MVC 5, но версия от версии отличается не слишком критично, поэтому и для 4 пойдет для начала. Это книжка уже чисто про веб-фреймворк, кое-что про сишарп там обзорно и лишь в самом начале, читать ее нужно уже изучив базу языка. Кроме того автор там пишет про паттерны (пресловутый MVC и его историей развития), техники написания юнит-тестов и внедрения зависимостей (IoC/DI). Книжка мегакрутая для новичка, но достаточно непростая, требует обдумывания и на некоторое время может стать настольной.

Обычно приложения делят на три слоя:

• Data Access Layer
  
• Business Logic (Domain models)
  
• UI (Web).
  

BL независим, DAL зависит от BL, UI зависит от DAL и BL (ибо там располагается интерфейсы биндятся на реальные классы).

Если мы рассматриваем классическую схему доступа к данным через репозитории, то:

BL содержит: доменные модели, интерфейсы для репозиториев, сервисы (интерфейсы и реализации, которые работают с репозиториями).
DAL содержит: реализации интерфейсов репозиториев (из BL), т.е. работу с DB, DbContext (от EF) и прочую конкретику о том, откуда и каким образом извлекаются данные.
UI (для ASP.NET MVC) содержит: собственно веб-проект с котроллерами *Controller.cs (Controllers), вьюшками *.cshtml (Views), вью-модели *.cs (Models, те специфические модели, которыми типизируются вьюхи, они могут отличаться от доменных (маппиться с них в контроллере), например, содержать объект с данными пагинации).

Также UI сожержит корень внедрения зависимостей, где связываются между собой интерфейсы и их реализации, например, интерфейсы репозиториев из BL и реализации (заточенные на работу с БД) из DAL.

Пример реализации.

ЗЫ Азы такой архитектуры применительно к ASP.NET MVC есть в замечательной книжке Фримана.