Ненорамалізований DLINQ

В неділю вирішив подивитись DLinq. Порівнювати мені майже нізчим, адже NHibernate я знаю доволі зверхньо (так вже вийшло що мені більш до сподоби генерування коду).

Першочергово я спробував з'ясувати чи є можливість хоча б теоретично налаштувавши все це для роботи з SQL 2005, потім змінивши щось (наприклад діалект), і отримати реалізацію наприклад для Oracle.

Одразу скажу, теоретична можливість є. Але схоже цим все і закінчується.

Для того щоб змінити базу даних потрібно змінити провайдер (System.Data.Linq.Provider.IProvider). Тут все майже добре, за виключенням того що реалізація такого DLINQ провайдера достатньо складна, і на відміну від провайдерів ASP.Net уся відмаркована як внутрішня (internal), тобто виходить що можливість є але скористатися єю достатньо складно. До речі, цікаво як довго в Microsoft міркували над назвою - IProvider ...

Припустимо що ми завершили написання/придбання/скачування потрібного нам провайдера. І тут наступає час коли ми щасливі пробуємо все це зібрати до купи з нашою вже існуючою доменною моделлю. І тут наступає просто цирк на дроті.

По-перше, для того щоб замінити провайдера потрібно у DataContext встановити атрибут ProviderAttribute (теж, до речі, певне результат декілька тижневого міркування...). Майже все добре. За виключенням декількох але...

1. В DataContext, можна ін’єктувати (inject) IDbConnection. Тобто інформація про провайдер вже є... Схоже її замало. Якщо передати туди OleDbConnection, отримаємо виключення... Цікаве архітектурне рішення;
2. По замовчуванню прямо в коді інстантіюється SqlProvider, невже команда яка це розробляла не могла подивитися на Asp.net де майже всі значення по замовчуванню можна встановити в web.config?
3. Список того що можна ін’єктувати (inject) в DataContext, просто супер.. IDbConneciton, string (рядок підключення) та IDbTrasaction.. Чому немає наприклад DbProviderFactory... чому саме IDbTrasaction? Ще мабуть цікаво як воно працює. Усі типізовані конструктори передають в єдиний метод який приймає object, а потім вже перевіряючи що в тому об'єкті налаштовують контекст ..

Друге, це налаштування мапінгу CLR типів на базу даних... Тут просто геніальне архітектурне рішення. Для кожної колонки DBType задається як рядок. Тобто наприклад якщо вам потрібен nvarchar(50), то саме так і треба писати... Більше того якщо, наприклад, це колонка з підтримкою NULL, то туди потрібно написати "nvarchar(50) NULL", ну і на останок "int NOT NULL IDENTITY"....  Де нормалізація даних? Адже якщо б дані були нормалізовані, то цим міг би займатися провайдер. З цього виходить... зрозуміло що виходить.. Виходить що потрібно буде відредагувати кожну колонку. Або перегенерувати модель. Зрозуміло якщо є чим. Тепер головне щоб Microsoft не закрили цей генератор. А то якщо окрім IProvider потрібно буде повністю свій генератор писати.

І ще декілька зауважень:

1. Є можливість повністю переналаштувати на роботу на stored procedures, єдине зауваження, це якийсь непрозорий (політика?) механізм, потрібен атрибут і спеціальний порядок параметрів. Також певне було б непогано, якщо б це можна було б якось автоматизувати;
2. Реалізація unit of work, тобто усі зміни будуть збережені в об'єкті, а вже коли ви викличте SubmitChanges запишуться в базу даних;
3. Підтримка транзакцій. Нормально. Але синтаксис підгуляв. Мабуть щоб хоча б частково вирішити проблеми з синтаксисом і додали конструктор з IDbTrasaction;
4. Система позиціонується як типізований шар доступу к даним. Тобто сгенеровані об'єкти можна використовувати як суттєвості, але краще не треба (привіт Entity Framework);