Роман

Простейший пример - сотрудники и группы. Сотрудник может входить в несколько групп, в группу может входить несколько сотрудников.

Пример из реальной жизни: Есть таблица товаров интернет-магазина и есть таблица акций, действующих на товары. Любой товар может участвовать в множестве акций и любая акция может включать множество товаров. И нет никакого способа хранить информацию об этих связях, кроме использования дополнительной таблицы.

То ли я от шарпа отстал, то ли второе вообще непонятно что.
Первое -свойство , имеющее только геттер.

ODP.NET это надстройка над ADO.NET?

Ну у вас и каша в голове, неудивительно, что вы ничего не можете найти.

ADO.NET - это прежде всего набор интерфейсов, обеспечивающих написание кода, работающего с реляционными данными таким образом, что он минимально зависит (или не зависит вообще) от конкретной используемой СУБД. ADO.NET это далеко не первая попытка унифицировать интерфейс доступа к базам данных (хотя бы к реляционным), многие крупные вендоры это делали, тот же Борланд.

С момента появления дотнета как платформы ADO.NET был и остаётся основным способом доступа к реляционным БД из дотнет-приложений. В большинстве случаев нет причин НЕ пользоваться им. Стоит отметить, что хоть сейчас MS советует использовать ORM (с тех пор, как повзрослел Entity Framework) для доступа к данным, ADO.NET никуда не девался, т.к. все известные мне ORM-ми работают также через эти интерфейсы.

Провайдеров данных существует множество, и существование каждого из провайдеров определяется существованием конкретной СУБД. ODP.NET это не надстройка над ADO.NET, это реализация интерфейсов ADO.NET, способная взаимодействовать с Ораклом. Аналогичные провайдеры существуют и для других популярных СУБД, включая PostgreSQL, DB2, MySQL и даже SQLite. По сути доступность реляционной СУБД на дотнете определяется наличием работоспособного ADO.NET-провайдера.

Разумеется, конкретный провайдер может добавлять какой-то специфичный функционал, но при этом он должен реализовать все необходимые интерфейсы. Фишка ADO.NET в том, что реально написать такое приложение (разумеется, если пользоваться только стандартными SQL конструкциями), которое ВООБЩЕ не будет зависеть от конкретной СУБД вплоть до того, что нужного провайдера можно будет указывать в конфиг-файле.

Большинство интерфейсов и классов ADO.NET находятся в пространстве имён System.Data. Условно они делятся на собственно интерфейсы для доступа к БД (важнейшие из них: IDbConnection, IDbCommand, IDataReader) и классы-хелперы, в частности набор классов для организации простейшей in-memory базы данных внутри вашего приложения, которая будет служить кэшем для данных, взятых из основной БД (важнейшие классы: DataSet, DataTable).

Слышал что есть управляемые и неуправляемые провайдеры данных, в чем отличие?

Я думаю, что речь идёт об использовании или неиспользовании неуправляемого кода в реализации провайдера данных.

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

>>для комфортной работы
Хочется отметить, что для комфортной работы студии + решарпера нужен так же довольно мощный комп. Лично меня тормознутость этой парочки перестала раздражать только на i7/16 Гб ram/ssd.

Это пробелы. Уберите галочку в (если отдельно плагин не стоит)

Edit -> Advanced -> View White Space

Async / Await - это сахар для оптимального использования пула потоков, можно обойтись без него, а если нужно использовать все треды на полную катушку, то следует использовать Async / Await.
Навскидку скажу только такие ситуации, где он необходим:
1) Чтобы избавиться от синхронных вызовов долгих вычислений в потоках, критичных к скорости выполнения. Как раз частный случай - пример, который описал Haze Max. Но нельзя забывать, что в WPF и WinForms, чтобы после этих вычислений что-то делать с окошком, нужно отмаршалиться обратно в UI поток.
2) Интенсивный IO - чтобы не останавливать поток, который ждет данные (либо пишет данные) от внешнего ресурса (hdd, сетевая карта например), исполнение кода следует переключать в асинхронный режим, чтобы избавиться от заморозки потока на время ожидания (пока происходит ожидание ответа, тред может выполнить какой-то еще код).

Реализуйте для модели интерфейс IEntity, чтобы в методе расширения использовать ограничение универсального типа:

public interface IEntity
{
	int Id { get; set; }
}

public class Model : IEntity
{
	public int Id { get; set; }        
	// ...
}

public static bool ExistById<T>(this DbSet<T> source, int id) where T : IEntity
{
	return source.Count(c => c.Id == id) > 0;
}