eddHunter Dec 18 2016 at 11:52

Готовим ORM, не отходя от плиты

16 min

16K

.NET*C#*

From sandbox

+10

Comments 38

lair Dec 18 2016 at 12:46

Также необходимо определить суперкласс для ограничения множества бизнес объектов, с которыми будет работать ORM.

Это сразу плохо. У вас инфраструктурный слой (репозиторий) просочился в виде давления в бизнес-слой. Нет никакой причины, почему все бизнес-классы должны наследовать от одного базового.

public abstract int Id { get; set; }

А если у меня не целочисленные идентификаторы?

Осуществить привязку бизнес объекта к таблице в базе данных на основе атрибутов

… и опять просочилась зависимость в бизнес-слой. Теперь я не могу создать бизнес-объект, не имея ссылки на сборку с атрибутами маппинга.

//в качестве аргумента базовому классу передаем название строки подключения

Зачем?

Бизнес-транзакция должна выполняться в рамках одного потока

Это почему? Все async запретили? И почему не использовать уже существующий TransactionScope?

var uow = new UnitOfWork();
using (Session.Create(uow))
{
var profileRepo = new ProfileRepository();
//Вызов методов репозитория
uow.Commit();
}

Нелогично. Вы диспозите и коммитите разные вещи. Совершенно не понятно, почему нельзя просто писать

using(var uow = new UnitOfWork())
{
  uow.Commit();
}

(без учета DI, но он и у вас не учтен)

public override bool Equals(object obj)
{
return obj.GetHashCode() == GetHashCode();
}
public override int GetHashCode()
{
//в пределах одной бд, тип объекта и идентификатор однозначно определяют его уникальность
var code = Key.GetHashCode() + Value.Id.GetHashCode();
//хэш код должен быть положительным числом
return code > 0 ? code : (-1) * code;
}

Колизии на хэшкодах от типов вас не смущают? А еще более смешной вариант "хэшкоды типа и идентификатора взаимно совпадают"?

Ну и зачем вообще это структура?

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

Почему?

Varim Dec 18 2016 at 17:22

Необходимо учесть, что бизнес объекты одной транзакции могут быть из разных бд. Логично предположить что для каждой бд должен быть определен свой экземпляр трекинга
Почему?

Там два предложения. «Почему» — к какому предложению задано?
А почему нет?

lair Dec 18 2016 at 17:36

Ко второму.

eddHunter Dec 21 2016 at 21:57

Все равно необходимо будет переключаться на другую бд, при выполнении запроса, так почему бы сразу не скомпоновать их по базам?
Объекты трекинга для одной бд(в простейшем случае, если нет зависимостей) не зависят от объектов в другой.

lair Dec 22 2016 at 08:45

Потому что порядок выполнения зависит не от базы.

sand14 Dec 18 2016 at 12:54

public override bool Equals(object obj) { return obj.GetHashCode() == GetHashCode(); }

Это же абсолютное зло.
Лучше разобраться с базовыми вещами, и только потом писать ORM или любые другие библиотечные вещи.

sand14 Dec 18 2016 at 13:10

var code = Key.GetHashCode() + Value.Id.GetHashCode();

Если вы по каким то причинам решили именно так (сложением) вычислять хеш-код, то лучше явно указать unckecked mode:
var code = unchecked(Key.GetHashCode() + Value.Id.GetHashCode();)

//хэш код должен быть положительным числом return code > 0 ? code : (-1) * code;

Во-первых, почему хеш-код должен быть положительным?

Во-вторых:

зачем (-1) * code, если можно написать просто -1?
зачем пытаться сменить знак для возможного нуля, если можно написать «return code >= 0? code: ...»?
что будете делать, если в code окажется Int32.MinValue? — при включенной проверке переполнения при умножении на "-1" получите OverlowException, при выключенной получите «Int32.MinValue» (а как же исходное «хеш-код должен быть положительным»).

eddHunter Dec 18 2016 at 15:13

Да, с unckecked, конечно, правы.
Положительный хэш нужен для корректного формирования текста и параметров sql запроса:

using (var command = conn.CreateCommand())
                {
                    command.CommandText = cmdBuilder.Invoke(command, objs);
                    command.CommandType = CommandType.Text;
                    conn.Open();
                    result = command.ExecuteListReader<T>();
                }

sand14 Dec 18 2016 at 16:54

Из статьи неясно, хеши объектов будут подставляться в запрос как идентификаторы? Если да, то это неверное решение. Если нет, то в для чего они используются при построении запроса?

Сам хеш в вашем случае нужно, для минимизации коллизий (а также для получения неотрицательного значения), вычислять примерно так:

public override GetHashCode() =>

(unchecked(someConstant * Key.GetHashCode()) ^ Value.Id.GetHashCode())

& Int32.MaxValue; // & 0x7FFFFFFF

И разберитесь с матчастью в части реализации Equals.

Varim Dec 18 2016 at 17:04

Положительный хэш нужен для корректного формирования текста и параметров sql запроса

Не знаю про какой sql сервер вы говорите, но в MS SQL Server, отрицательный int в PK никто не запрещал.

sand14 Dec 18 2016 at 20:02

+Более общее соображения, что использовать хеш в качестве ключа в БД нельзя
Об этом прямо здесь прямо написано:

A hash code is not a permanent value. For this reason:
Do not serialize hash code values or store them in databases.

То же самое и в других платформах — Java и любой другой, вследствие природы хеш-кода объекта.

merlin-vrn Dec 18 2016 at 19:01

если можно написать просто -1

-code

sand14 Dec 18 2016 at 19:58

именно это.

MonkAlex Dec 18 2016 at 14:54

Приходит новый человек на проект, а там вместо привычных EF или NHibernate — свой велосипед, со своими багами, со своими ограничениями. Очень позитивно.

eddHunter Dec 18 2016 at 15:06

Я и не писал, о необходимости своих велосипедов. Я о том, что лучше дать новому человеку больше инфы о принципах лежащих в основе работы, дабы избежать любой неопределенности.

Xandrmoro Dec 18 2016 at 19:02

А заодно со своими возможностями, некоторыми из которых в EF не пахнет.
Сделать действительно всеобъемлющий ORM невозможно в силу принципиальной разности концепций, всегда что-то приносится в жертву.

MonkAlex Dec 18 2016 at 19:13

Не знаю насчет EF, но NHibernate мне хватает по самое не могу даже на крупных проектах. Боюсь представить, что вы там изобрели такого, что вам не хватает.

Xandrmoro Dec 18 2016 at 19:22

Автоаудит в отдельные таблицы, CTE, инлайнинг вьюшек, оконные функции.

MonkAlex Dec 18 2016 at 21:38

Я если честно из этих терминов встречал только «оконные функции» и те в другом контексте. Сможете пояснить, как это примерно хотелось бы использовать и зачем?

Xandrmoro Dec 21 2016 at 18:44

Автоаудит — это когда кто-то где-то что-то поменял, и в специальную табличку (в моём случае — почти каждая таблица с данными имеет свою собственную таблицу аудита) пишется, кто, что и когда. Можно сделать триггерами, но, во-первых, триггеров нужно катастрофически много, во-вторых — сложно определить юзера.

CTE — это такая фича T-SQL, когда можно в рамках запроса объявить что-то вроде вьюшки и потом пользоваться ей. В духе

WITH someCTE AS (
  SELECT a, b FROM (
    SELECT a, b FROM table1
    UNION 
    SELECT a, b FROM table2
  ) un LEFT JOIN table3 t3 ON (t3.a = un.a)
)
SELECT c
FROM table4
LEFT JOIN someCTE cte on  (cte.a = table4.c)
LEFT JOIN (
  SELECT * FROM table5 INNER JOIN someCTE cte ON (cte.a = table5.a)
)
-- любая другая хтонь

Оконные функции — такая штука, позволяющая агрегировать (и делать некоторые другие вещи) данные без группировок. Или, например, опираться на значение из нескольких строк. Скользящие средние, номера строк внутри групп, средние/суммы/чтоУгодноЕщё по группам,… you name it.

Инлайнинг — это когда вьюшка подставляется в запрос путём собственно вставки её текста в подзапрос. Зачем?
Допустим, у нас есть некоторая очень тяжёлая вьюшка, которую нельзя проиндексировать (лефт джойны, недетерминированные функции, таблицы из разных баз, да что угодно). При этом на неё накладываются достаточно жёсткие условия, уменьшающие её на несколько порядков:

SELECT * FROM matters m
LEFT JOIN view1 vw ON (vw.matterId = m.id)
WHERE vw.UserId = 150

Часто можно это самое условие наложить где-нибудь внутри:

SELECT * FROM matters m
LEFT JOIN (SELECT * FROM users /*много-много джойнов*/ WHERE vw.UserId = 150) vw -- текст вьюшки
ON (vw.matterId = m.id)

И получить эти самые порядки прироста производительности. Table-valued функции при этом использовать не представляется возможным, потому что фильтры заранее неизвестны.

MonkAlex Dec 21 2016 at 19:06

Почти все перечисленное — только для голого sql в условиях проседания производительности. Слабо верится, что можно на это дело адекватно ОРМ написать.

Некоторые вещи имхо просто не нужны в крупных приложениях с ОРМ, например первая =)

Xandrmoro Dec 21 2016 at 19:47

Десять миллионов строк, тридцать терабайт данных и Пепси, GM и Дисней в клиентах — достаточно крупное приложение? :)

И все они интегрированы в кастомную ОРМ.

MonkAlex Dec 21 2016 at 21:27

Так ОРМ для упрощения работы с базой, а не для производительности.

Ессна, что типовые решения не подойдут на большие нагрузки, но и начинать с кастомной ОРМ ради этого точно не стоит.

ПС: пилите на здоровье, раз кто-то готов оплачивать. Ура, как говорится =)

eddHunter Dec 21 2016 at 21:46

EF и Hibernate, изначально не создавались для вашего проекта.
Выбор ORM должен быть продиктован задачами вашего бизнеса.
Например, если у вас на проекте или на какой-то его части, большинство запросов легкие, read only, тогда использование тяжелого EF никак не улучшит перформанс — это стрельба из пушки по воробьям. В этом случае стоит написать свое(как и сделали в Stack Overflow).

eddHunter Dec 21 2016 at 22:18

Зачем для использования временных таблиц или CTE, писать ORM?) В EF или Nhibernate никто не запрещает вам создать обертку ХП, в которой можете развлекаться с sql как угодно.

eddHunter Dec 18 2016 at 20:59

Данное решение for fun, не более того, конечно.

eddHunter Dec 19 2016 at 01:54

Это популизм. В первой строчке статьи, я написал о об этом. Этот проект типа for fun.

eddHunter Dec 19 2016 at 01:58

Конечно, нет спора лучше чем свой костыль vs EF vs Hbn vs Dapper и т.д.

Varim Dec 18 2016 at 17:16

Сразу определимся с терминами: под трекингом будем понимать отслеживание изменений бизнес объектов в рамках одной транзакции, для дальнейшей синхронизации данных, хранящихся
в оперативной памяти и содержимого бд.

Слово синхронизация на мой взгляд не подходит, так как предполагает двухстороннее взаимодействие DB<->RAM.
То есть когда стороннее приложение пишет в БД, трекинг БД кидает сообщение в ORM, вызывая обновление объекта в RAM, как в ADO.NET SqlDependency (ALTER DATABASE <db_name> SET ENABLE_BROKER;).

В вашем случае лучше как то так — «для дальнейшего сохранения данных, хранящихся в оперативной памяти в ~~содержимое~~ бд».

eddHunter Dec 19 2016 at 01:46

Слово «синхронизация» подходит полностью. Причем тут инструкции типа ALTER?

Varim Dec 18 2016 at 17:27

//регистрируем «чистые» объекты путем копирования полученных из бд,
//исходные считаем «грязными»

Обычно чистые те которые получены из бд.
Как только чистые-БДшные сущности изменили, их называют грязными, до тех пор пока их не сохранили в БД.

eddHunter Dec 19 2016 at 02:05

Я о том и писал, что «dirty objects», это те, кто сохранили свою ссылочную целостность до сохранения в бд.

Varim Dec 18 2016 at 17:38

Потом, когда и если доведете ORM до ума, в метод ChangeDirtyObjs можно добавить построение и кэширование Expression Trees, что бы долго не ходить рефлексией по var props = type.GetProperties();
Первый раз получил type, построил Expression Tree, закэшировал, следующий раз если есть в кэше есть type, вызвал Expression

eddHunter Dec 19 2016 at 01:39

Да, конечно, https://habrahabr.ru/post/269699/, знаем. Пока было глупо описывать такие дебри.

dotnetdonik Dec 18 2016 at 19:43

Вы замахнулись на очень сложную задачу и допустили в ней очень много ошибок проектирования и пропустили антипатернов.
Начинать всегда стоит с простых вещей, построение запросов и Change Tracking это не первоочередного порядка вещи в ОРМ, а плюшки вендора скорее.

У вас очень много ошибок с тем как вы выстраиваия уровни абстракций и интерфейсы для разных задач. Реализация так же подводит, работа с блокировками, dispose обьектов, object equality и асинхронностью.

Асинхронные методы возвращающие void и вызывающие синхронный i\o api — грубейшие ошибки.

public void Commit()
{
SaveChanges();
}
private async void SaveChanges()
{
await Task.Run(() =>
{
}
);
}

eddHunter Dec 19 2016 at 01:40

Не могли бы разъяснить?

dotnetdonik Dec 19 2016 at 06:52

https://msdn.microsoft.com/en-us/magazine/jj991977.aspx

Этот код не дает возможности обработать ошибки вызывающему коду, на тред пуле выполняете блокирующую i\o операцию, да еще и потом синхронизируеться неявно в конце через execution контекст выбрасывая silent ошибки.

Если говорить про Asp.Net например, ваш Save changes выполниться уже когда пользователю прийдет ответ в браузере.
Мне не совсем понятно зачем там используется Task.Run — но он там используеться неправильно.

eddHunter Jan 12 2017 at 00:57

Да, спасибо. Я так понимаю надежней для библиотечных вещей использовать ConfigureAwait(false) чтобы сказать системе, что она не должна выполнять фоновую задачу в вашем контексте http/GUI.