Готовим ORM, не отходя от плиты. Генерируем SQL — запрос на основе бинарных деревьев выражений

Вы, правы. Вот и задачка появилась, переписать на этот паттерн )

Готовим ORM, не отходя от плиты. Генерируем SQL — запрос на основе бинарных деревьев выражений

Знаю, но цель моего досуга в реализациях с нуля. Но я должен был упомянуть об этом в статье, поправлю.

Готовим ORM, не отходя от плиты. Генерируем SQL — запрос на основе бинарных деревьев выражений

Это гипотетическое упражнение, конечно. Меня они так или иначе устраивают.

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

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

Аналог .Net Entity Framework в Delphi посредством RTTI. Часть первая, вступительная

На delphi я программировал на младших курсах ВУЗА, поэтому интересно: лямбы появились в delphi?
Если да — аналог linq можно и самому написать по приколу)

Аналог .Net Entity Framework в Delphi посредством RTTI. Часть первая, вступительная

Было бы не плохо найти способ закешировать маппер классы, дабы каждый раз не обращаться к рефлексии.

Модульное тестирование в современных командах

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

Модульное тестирование в современных командах

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

Это глубокое заблуждение.

• Во-первых — ручная проверка front части останется необходимой, в той же мере, что и раньше. К тому же у вас нет тестов на фронт.
• Во-вторых — это тема сугубо для разработчиков. Модульное тестирование, прежде всего, призвано задокументировать функционал, оптимизировать архитектурные решения, а не сколько поправить критические баги, на то скорее интеграционные тесты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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