Как стать автором
Обновить

Комментарии 17

Рекомендую обновить readme на гитхабе. Сейчас там нет никакой информации об использовании. Я понимаю, что есть тесты, но первое впечатление о проекте складывается именно по readme-файлу, как мне кажется
Благодарю! Вы правы, readme стоит обновить. Столько всего хотелось сделать, что до него руки так и не дошли пока…
Обновил readme.
Стоит изначально добавить поддержку .NET Standard Library — это позволит использовать ваш фреймворк из ASP.NET Core приложений. На ранней стадии это сделать проще.
Спасибо! Хорошая идея!
Что значит нет абстрагирования? Если Вы его не используете, это не значит, что его нет.
Я перечислил классы DbConnection/DbCommand. Да, через DbProviderFactory можно получить DbConnection, а через него DbCommand и т.д. Но я говорю вот о чем: в случае скажем с PostgreSQL не приводя DbDataReader к NpgsqlDataReader (http://www.npgsql.org/api/Npgsql.NpgsqlDataReader.html) невозможно получить например NpgsqlTimeSpan (функция NpgsqlDataReader.GetInterval). TimeSpan сейчас еще не поддерживается фреймворком. Но это как раз является причиной использования конкретных реализаций.

применив не общие типы вы уже отказались от абстрагирования.

Не совсем. Все-таки в интерфейсы оберток можно добавить любые методы, в реализациях выкинуть NotSupportedException, если СУБД по тем или иным причинам не поддерживает тип. Те интерфейсы которые объявлены в проекте будут использоваться одинаково, вне зависимости от того, какая реализация под капотом.
Почитал мат. часть. Да, похоже что нужно ввести метод, который проверяет поддерживается ли определенный тип обёрткой или нет. Спасибо за замечание, учту!
Есть очень похожий проект, Insight.Database, не смотрели? Использую его у себя в проекте, очень правильный на мой вкус градус удобства и черной магии под капотом.
Посмотрел, да похоже, но концепция ближе к EF всё-таки.
Спасибо! Посмотрел пока мельком — то чего не хватало когда писал (превращение в SQL подобное с Select/Where писал сам и в данный момент в этой части кода пока не очень все нравится. Посмотрю подробнее.
На помощь нам придут Expression'ы и возможность их компиляции «на лету». Идея состоит в том, что тело функции генерируется, компилируется и ссылка на нее сохраняется в виде делегата. Делать это необходимо только один раз – при инициализации.


А почему не кодогенерация?

Поясню:
1. Генерированный код можно посмотреть и отладить, решарпер будет проверять его и делать подсказки. А вот у Expression такой штуки нет.
2. Expression требует обязательного прогрева, кодогенерация его не требует.
Я использовал Expressions по следующим причинам:
1) компилируется минимум и функции просты до безобразия. Все, что можно не компилировать — не компилируется. Кроме того, кроме компиляцию создаются ещё некоторые вспомогательные структуры для конструирования как встроенных во фрейморк, так и кастомных запросов. Сгенерированные функции проверять каждый раз решарпером — думаю это лишнее, остальной код проверить конечно же можно.
2) их всего три и вряд ли предвидится больше.
3) не хочется никаких лишних действий кроме как использовать репозиторий и передать ему модель (в том числе унаследовать и добавить функции).
4) в силу природы отложенной инциализации репозиториев разогрев будет сущим пустяком по времени (я не думаю, что за один запрос будет использовано более 10 репозиториев).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории