Павел Новиков "Что не так с ORM?"

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

Transcript

1. Что не так с OR/M? НАДО СРОЧНО ОБ ЭТОМ ПОГОВОРИТЬ
2. Надо сказать кто я
3. Надо уточнить у аудитории У вас бывало такое, что вы пишете-пишете проект с O/RM… А он – раз и говно?
4. Надо рассказать как оно бывает Докладчик импровизирует, иронически обыгрывая энтузиазм, с которым мы начинаем новый проект и не подозреваем что что-то может пойти не так
5. Надо рассказать как оно бывает Прямой SQL и групповые операции (UPDATE … WHERE / DELETE … WHERE) Это Мартин Фаулер, если кто не знал
6. Надо рассказать как оно бывает Одно из компромиссных решений Я описывал как это работает в своей статье на хабре Прямой SQL в EntityFramework. Теперь со строгой типизацией
7. Надо рассказать как оно бывает Bulk Import
8. Надо рассказать как оно бывает Быстро Правильно SqlBulkCopy dataContext.Users.Add(user);
9. Надо рассказать как оно бывает Грануляция Ну и куда это класть?
10. Надо рассказать как оно бывает Грануляция Вот и ладушки!
11. Надо рассказать как оно бывает Грануляция
12. Надо рассказать как бывает Делаешь правильно – тормозит. Делаешь быстро – не обслуживается
13. Надо донести страшную правду Рефакторинг вас не спасёт Нет никакого «волшебного O/RM», который решит все проблемы Нет никакой специальной архитектуры приложения, которая утешит вашу печаль Но почему?
14. Надо добавить умных слов Протекающая абстракция Object-relational impedance mismatch База данных – не коллекция
15. Надо как-то объяснить Коллекция База данных Легко работать с каждым элементом по отдельности Сложно работать с каждой строкой отдельно, но легко работать с группой данных, заданной аналитически Состояние меняется здесь и сейчас Состояние (относительно приложения) меняется когда-то потом и вообще не факт что Можно отсортировать коллекцию Индексы, статистики для ускорения поиска Работа со связями через ОО-средства Работа со связями принципиально по-иному (FK, таблицы связей) .Add, .Remove, .Find Сложный интерфейс работы, подразумевающий использование разных средств и техник для обработки данных на своём DSL
16. Надо как-то объяснить O/RM урезает огромный и развесистый API базы до API коллекции из трёх методов. База данных O/RM
17. Надо попробовать решить проблему Метафора «класс представляет таблицу в базе, экземпляр его – строчку, а проперть его - колонку» - это хорошо. Маппинг, конфигурация, миграции – всё это тот же EF делает приемлемо. Заметьте!
18. Надо попробовать решить проблему Предложение номер 1 Логически запросы и запись данных – абсолютно разные и не связанные друг с другом вещи. Следствие: для запросов нужен один протокол работы, а для изменения данных - другой
19. Надо переработать IQueryable
20. Надо сделать интерфейс хранилища
21. Надо вынести запросы
22. Надо заметить что удобно
23. Надо заметить что удобно Прикиньте сколько фигни сразу исчезает из бизнес-логики?
24. Надо порадоваться Плюсы ◦ Запросы – чистые функции без сайд-эффектов (удивительно!) ◦ Не занимают места в бизнес-логике (для запросов вообще не надо сервисов) ◦ Не возникает проблем грануляции (берёшь корневую сущность, от которой строится запрос, пихаешь в IQueryFor, пишешь extension) ◦ Автоматические имена ◦ Да, мы так делали в живом проекте и это действительно работает, разгружая слой логики от запросов Минусы ◦ Методы запросов бывает сложно найти легко потерять и невозможно забыть
25. Надо что-то делать с логикой Предложение номер 2 Задача всего O/RM-слоя – фактически, сформировать SQL и пульнуть его в базу данных. Следовательно: надо рассматривать бизнес-логику именно как процесс формирования очереди SQL- команд для последующей отправки в базу. Но при этом не опускаться до прямого SQL-я.
26. Надо что-то делать с логикой Введём концепцию скрипта изменений
27. Надо что-то делать с логикой И начнём накидывать в него методы-метафоры для SQL
28. Надо что-то делать с логикой
29. Надо что-то делать с логикой
30. Надо что-то делать с логикой Ну и так далее. Можно делать If, Exists, Declare, итерацию курсоров, какой-нибудь WithUploaded, который копирует данные в базу через SqlBulkCopy и делает апдейты/инсерты – всё, что в голову взбредёт. Важных момента 3: ◦ Нет EF-ного трекера сущностей, не оперируем с БД как с коллекцией ◦ Используем C#-метфоры для SQL-я. Да, фактически это DSL для SQL поверх C# ◦ На выходе получаем пачку изменений, которые надо накатить на БД (можно сделать offline- реализацию)
31. Надо что-то делать с логикой Как изменятся сервисы логики Инжектица
32. Надо что-то делать с логикой
33. Надо что-то делать с логикой Это пока наброски и прототипирование, не бейте тапками. Для реализации мне нужен AST для SQL-я (что сложно). И конструктор запросов спереть из EF (но боюсь что дадут по башке)
34. Надо ответить на вопросы Вопросы?
35. <EOF>