ADO.NET, упоротые черти

В своем стремлении впихнуть все, что пришло в голову, проектировщики ADO.NET наделали такого, что теперь в нем сам черт ногу сломит.

Вот к примеру: есть запрос, выбирает данные из таблицы БД и ложит их в DataTable. Ложит методом "DataTable.Load(IDataReader reader)".
Так вот, если запрос из которого мы получили оный reader - это просто select ... from table, то эти умники меняют схему DataTable, заполняя ее констрейнтами, соответствующими таблице, в том числе и описанием первичного ключа. Соответственно, если у меня этот ключ автозаполняемый на сервере и заполнять его не надо, то все равно - вставить более одной записи с пустым ключом в DataTable не получится - ругается на то что такое значение уже присутствует.
Но если запрос содержит join с другой таблицей - то схема DataTable уже не меняется и вставить несколько записей с пустым ключем можно.

Я никогда не понимал этого стремления "впихнуть в код все сразу", особенно если четкого понимания, что именно делается, нету.
А второй вывод - лучше бы я руками эту таблицу из IDataReader заполнил, вместо вызова стандартного метода Load. Практика работы с дотнетом показывает, что использовать "стандартные методы" в нем очень сильно не рекомендуется, т.к. способ мышления их авторов иначе чем терминологией ребе theiced описывать не получается.

Любовь к выдумыванию собственных типов.

Как же откровенно задолбал один момент при работе с базами данных, ORM и прочим. Каждая собака бешеная считает своим долгом сначала сделать собственное перечисление типов, а затем с усердием, достойным лучшего применения писать конверторы ".NET тип <-> DbType <-> EdmType", итд, итп.

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