WildData: lightweight data access framework

Антон Подавалов, “WildData: легкий фреймворк доступа к данным”, public translation into English from Russian More about this translation.

Translate into another language.

Good day, %username%! Here I dared to write an article for this portal. I’m going to talk about data access layer for .NET (C#) application. All my thoughts/ideas and in what they turned, I am going to express below. Welcome!

Every time I will speak about DMBS I will mean an relational DBMS. Looking forward, I would like to say that an introducing library (framework) is not Entity Framework replacement and has nothing to do with it.

Nevertheless, the Entity Framework is good (may be the best) attempt that introduces abstract data access. In other words, it takes a user away from specific DBMS.

Every DBMS has its advantages and disadvantages. Many of them have some specific features. Some of them are the best in a field, some of the are the best in another. Let’s assume that after some thoughts we have chosen an DBMS to implement some great (or not so great) project and decided to write it using … ADO.NET.

Advantages of ADO.NET

1. Total control on queries;

2. Simple scenario: create connection, create transaction (optional), create command, specify command text and parameters, run query, read data (optional).

3. Supports almost all DBMS.

4. Close interaction with DBMS (i. e. supporting "non-standard" types like geography coordinates, JSON, etc).

Disadvantages of ADO.NET

1. Для каждой модели необходимо каждый раз заново писать код для чтения, добавления и изменения записи в БД – проще говоря отображения объекта на запись в таблице, представлении т.д. и, наоборот, отображение записи на объект;

2. Нет абстрагирования как в Java (хотя есть DbConnection/DbCommand и другие классы, но часто используются конкретные типы, например SqlConnection/SqlCommand);

3. Нет универсальной поддержки работы с пакетом записей (добавление, обновление, добавление или обновление, удаление);

Вероятнее всего читатель уже догадался, что мы будем думать как избавляться от вышеупомянутых недостатков. Поговорим о том, что является ключом к реализации всего проекта.

Начнем по порядку.

1. Что же мы можем сделать для того, чтобы написать этот код один раз? В первую очередь заметим, что костяк для чтения одного или нескольких объектов остается неизменным вне зависимости от того что это за объект и какие поля он содержит. Это означает, что нам необходима универсальная функция чтения одного объекта. То же верно для добавления и обновления записи.

Как такая функция должна быть написана? Первое что приходит на ум – Reflection. Допустим. Но у Reflection есть один существенный недостаток – он медленный. Если при чтении/добавлении/изменении/удалении одного объекта быстродействие просядет несущественно, то при большом количестве объектов накладные расходы будут ощутимы.

На помощь нам придут Expression'ы и возможность их компиляции «на лету». Идея состоит в том, что тело функции генерируется, компилируется и ссылка на нее сохраняется в виде делегата. Делать это необходимо только один раз – при инициализации.

С чем должны работать функции? С тремя сущностями:

- объект как таковой (модель);

- объект чтения данных (например, SqlDataReader);

- коллекция параметров (например, SqlParameterCollection).

Для того, чтобы точка генерация данных функций была едина, введены следующие интерфейсы обёрток: IDbParameterCollectionWrapper и IReaderWrapper (см. ссылку на репозиторий проекта ниже). Для каждой СУБД необходимо реализовывать эти интерфейсы индивидуально. Забегая вперед: фреймфорк нацелен в первую очередь на скорость работы, поэтому в ряде случаев используется отложенная («ленивая») инициализация. Так же фреймфорк содержит несколько вспомогательных атрибутов для бóльшей гибкости (например, вычисляемые поля, обязательные поля и т.д.).

2. Вся общая часть фреймфорка вынесена в отдельный общий проект. Для пользователя видны в основном интерфейсы. Крайне рекомендуется пользоваться только интерфейсами.

3. Пакетная работа с записями пока не реализована, но это уже «дело техники».

Проект уже можно опробовать (см. ссылки ниже). Имеется поддержка Linq! Проект в альфа-версии, поэтому код пока неидеален.

Что планируется добавить:

- больше тестов;

- поддержка других баз данных: в первую очередь SQL Server, MySQL;

- поддержка Microsoft.AspNet.Identity.

Ссылки:

- Проект WildData на GitHub.

- Nuget-пакет WildData.

- Nuget-пакет WildData (реализация для PostgreSQL).

- Очень простой пример использования фреймворка.

Строго прошу не судить. Это моя первая статья на хабрахабре. Спасибо за внимание!

P.S. По всем вопросам прошу в личку и комментарии.

Original (Russian): WildData: легкий фреймворк доступа к данным

Translation: © apodavalov .

translatedby.com crowd

Like this translation? Share it or bookmark!