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

EF вам дает возможность автоматически транслировать экспрешны в диалекты SQL и маппить это на удобные дотнетные сущности. С голым ADO.NET вы будете делать то же самое, но руками.

куда логичнее было бы, чтобы в объекте Order было поле типа Client, в котором лежит объект компании-получателя, а не условный int с идентификатором.

Предлагаемая вами схема денормализована, вообще говоря, это не очень хорошо. Но посмотрите на Owned Types для EF Core и на Complex Types для EF6, мне кажется, что это то, что вы хотели бы - "встраивать" один объект в другой, сохраняя всё в единой таблице.

Да, EF не то, чтобы позволяет сильно отходить от классической реляционной модели, но с ним можно точечно звать raw sql-queries, что даст больше гибкости там, где это необходимо.

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

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

Это для получается для каждого репозитория нужно писать getter/setter в главном репозитории? Очень много и накладно.

Это можно решать метапрограммированием через Reflection API и дженерики.

Для переключения между субд я решил сделать Фабрику. Но на этом и возник ступор.

Реализации фабрик для этого уже написаны и называются IoC-контейнерами. Принципы работы с ними можно посмотреть здесь. Ну или где угодно в интернете. Популярные реализации: Castle Windsor, Unity, Ninject и т.п.

Суть в том, что контейнер сначала можно настроить:

interface IMyEntityRepository {...}
class MySqlEntityRpository: IMyEntityRepository  {...}
...
config.Bind<IMyEntityRepository>().ImplementsBy<MySqlEntityRpository>();

А потом позвать:

var repo = ioCContainer.Get<IMyEntityRepository>();

Кроме очевидных плюсов, IoC-контейнеры могут:

1. собирать полный граф зависимостей по своей таблице (A зависит от B, B от C и т.п., внедряя необходимые реализации автоматически, т.е. мы можем создавать сразу A)
   
2. конфигурироваться без перекомпиляции (autowiring (автоматический поиск реализаций заданных интерфейсов) или по информации из конфиг-файла, вроде XML).
   

Не нужно хранить в базе 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 не нужен. Тем более, что название свойства - тавтология).

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>
Извлекать значения, соответственно, из ресурсов.

Вы выбрали не тот тип проекта.

Restore packages, как и project.json, существуют только для проектов под рантайм .NET Core. Предлагаю погрузиться в документацию.

Вам также может быть полезна эта статья.

Есть язык ANSI SQL, он как идел, в чистом виде нигде не существует, каждая СУБД его придерживается, но вносит свои фишечки, которые делают его не полностью совместимым с другими СУБД. SQL с "фишечками" в конкретной СУБД назвается диалектом SQL. В MS SQL Server свой диалект - Transact-SQL. А еще в SQL Server можно встраивать .NET-сборки.

EF из объектов и выражений генерирует T-SQL-код, отправляет SQL Server и парсит ответ снова в C#-объекты с учетом их связей, почему и называется ORM-фреймворком.

Как правильно говорят, EF и прочие ORM не освобождают от необходимости знать SQL и того, как там организуются связи. Ибо на собеседосах все равно будут заставлять писать SQL на листочке, а на практике во имя бога производительности вы все равно будете писать хранимые процедуры на T-SQL. Так что работать с ADO.NET нужно уметь, даже не смотря на то, что это выглядит достаточно антично в наш хипстерский век.

особенности Mono...её отличия от "оригинальной" .Net

www.mono-project.com/docs/about-mono/compatibility

Троелсен упоминает о "серьёзных оговорках" при компиляции языков, удовлетворяющих требованиям спецификации CLI в CIL.

Вероятно, речь идет о том, что не все языки поддерживают все возможности IL и чтобы библиотеки нормально можно было использовать в мультиязычной среде, нужно следовать некоторым ограничениям - CLS (Common Language Specification). Об этом лучше читать у Рихтера.

Можете почитать лицензионное соглашение MSVS Community 2017. Вкратце: мелким организациям и ИП - бесплатно.

Важно отличать ASP.NET MVC и ASP.NET Core. Под первую пишут на виндах и под винду, второй - некоторой степени сырости (но жить можно), который можно использовать полностью бесплатно в любых масштабах.

То есть для крупной организации это может быть от бесплатного .NET Core-решения на Linux (VS Code + ASP.NET Core + MS SQL Server Express), до полностью платного стека:

1. MS Windows (на сервер, IIS в комплекте),
   
2. MS SQL Server (на сервер),
   
3. MS Windows для разработчика,
   
4. MS Visual Studio для разработчика
   

Я Студент.

Студент какого учебного заведения?

Шилдта в руки и вперед!

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

А какой результат вам нужен? Хэлловорд сможете написать уже через час, а нормально что-то писать начать средний человек может через полгода-год.
5-6 часов в день - это очень дофига для изучения. Я бы даже сказал, этого слишком много, ибо поглотить информации можно больше, чем "переварить", в голове образуется стылая плотная масса необработаной информации, которая с разных сторон торчит ключевыми словами. Оптимально - это 3-4 часа (2 на теорию + 1 на эксперименты с кодом) + здоровый сон в 7 часов.

Во-первых, вы куда-то торопитесь? Не стоит, ничего гениального в ближайший год из-под пера не выйдет, это нормально. Сначала учитесь худо-бедно что-то примитивное писать, параллельно изучая API FCL, потом на этой базе делать маленькие тулы. Затем беретесь за серьезную литературу, вроде Рихтера и познаете суть CLR. Знания C/C++ здесь могли бы пригодиться, если вам их будут преподавать. Затем "Банду четырех" и учитесь примитивы собирать в кучу грамотно, используя паттерны разработки. Параллельно осваиваете кучу новых языков и технологий, экспериментируете (без этого есть риск быстро выгореть и забросить программирование). Полезно устроиться и где-то поработать некоторое время, попилить опенсорс. Ментор - это здорово, но не обязательно. Остерегайтесь платных курсов, любите книжки.

И, главное, если действительно хотите научиться хорошо программировать, тогда не ограничивайте себя Unity (где C# - это язык скриптов, наравне с JavaScript), оттачивайте знания, копайте глубже фреймворков, интересуйтесь IT, учитесь решать реальные проблемы. Ведь это не самая плохая профессия, которая сможет сделать вам будущее.

Начнем с терминологии, а то хейтеры тут не особо разбираются =) Между ASP и ASP.NET MVC разница примерно такая же, как между Java и JavaScript.
Java - это язык, как и C#. Под них есть свои веб-фреймворки, такие как JavaEE, Spring для Java или ASP.NET MVC, NancyFX для C#.

Учить ASP (classic ASP) или ASP.NET (который Web Forms) с нуля уже не стоит. А вот ASP.NET MVC - отличный выбор. Это уже достаточно зрелый фреймворк, на котором работает много серьезных проектов (таких, как StackOverflow) и которая востребована на рынке как в России, так и в мире.

Сам C# достаточно интересный, активно развивающийся язык. Платформа себя чувствует неплохо на любых популярных устройствах. Хорошо развивается .NET Core, являющийся переосмыслением монолитного .NET Framework, позволяющий разрабатывать компатные кросслатформенные приложения, в том числе и с использованием ASP.NET Core, которые можно развертывать самостоятельно, без огромного сервера за спиной, аналогично Node.js.

Конечно, с ASP.NET MVC не пофрилансишь и сайты-визитки разрабатывать не так удобно =) Но поддерживать крупные приложения - одно удовольствие.

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

Выглядит как сравнение "хардкод vs контейнер". Разница очевидна: Dictionary обеспечивает поиск со сложностью O(1) (против O(n) у свича) и способен динамически расширяться.
В контексте задачи это похоже на DI для бедных. В этом случае Dictionary будет нагляднее.