четверг, 1 июня 2017 г.

ORM - это обидно




Обычная схема работы: создается объект (с сетером) и отдельная сессия, которая забирает геттером информацию для записи её в БазуДанных.

код соотвествующий схеме
Объекты выступают, как носители данных, и ссесии как управляющие этими данными. Это не объектно.
  • ООП - объекты прячут от нас данные и работа происходит на более высоком уровне абстракции;
  • Процедурное программирование - код управляет непосредственно данными, данные открыты.
Главное проблема с процедурным программированием - трудно поддерживать такой код. А из Java пытаются делать C++
Инкапсулировать поведение внутрь объекта и не выдавать данные наружу. Убрать геттеры, перестать делать объект хранилищем данных из которых можно что то достать. Это не глупая корзина с примитивами
Мы должны доверять объекту, уважать его. Поэтому он должен сам делать то, что нужно. Мы должны объединить и данные и функционал. Объект должен сам решать, что предпринять.

DTO Data Transfer Object - это не правильно, это антипатерн. Это совершенно не тестируется

Вы писали тесты на гибернетйте? Это крайне сложно - набор пустых дата объектов и процедуры, от которых ушли 40-30 лет назад 
 
Да, это можно тестировать интеграционным тестированием - но это уже не юнит тест, выполняющийся  за миллисекунды.

Здесь нет логики….. что тестировать?

Объекты — данные, везде, везде, а код — в процедурах

да конечно можно поднять на новый уровень и тестировать, как объект меняющий пользователя

Интеграционное тестирование - это тестирование очень большого объекта, а юнит тестирование - это тестирование маленького объекта SingleRespPrincip

В гибернейт мы этого сделать не можем потому что объекты — структура данных а не реальный объект

Самая большая проблема — ORM не делает маппинга, мы все равно остаемся в реляционной модели, мы не можем воткнуть NoSQL потому что модель у нас реляционная.

И DAO тоже не спасает ситуацию… тем более что он и не всегда строится (прям лепят во View если это MVC и на этом все заканчивается - конечно так делать не надо но люди делают). Идея разделения на глупые и сверх-объекты неправильна.

Мы не только DAO должны любоваться, как красивым и мощным объектом, нам должен нравиться каждый из объектов.
 
Решение:

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

Не 2 объекта… в разных местах… ssesion в БД , и там еще где то… а он один отвечает за свое собственное переименовывание

вот как это будет выглядить
 
теперь этот класс User полностью изолированная структура, его можно тестировать… теперь все кто от него зависят не знают что у него внутри и им это и не надо

  
jOOQ библиотека отвечает за драйвер к СУБД. Теперь мы можем спокойно поменять БД на другу, для этого он и вставлен.

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

Да, он делает запрос к БД, и так делают и остальные 10 миллиардов объектов… а вот чтобы это все не рухнуло, мы должны сделать оптимизацию, завернуть их в декоратор.

Если у нас множество совершенно разных запросов, то мы их не пихаем в один объект мы используем другой дизайн (декоратор в декораторе в декораторе) но в любом случае мы сами принимаем решение, а не гибернейт или еще кто-то.

Декораторов много да, но они ничего не знают про ОРМ, декораторы маленькие понятные в коде, они как слои их хоть десятки и они занимаются только одной задачей.

Вы полагаетесь на поведение объекта, но не знаете каков он внутри, и в этом идея инкапсуляции

Вы не знаете что внутри объекта. И какой он к вам пришел … логгирует ли себя, прерывает, с какой БД работает, этих знаний вам не дается. Вы просто вызываете нужный вам метод, а дальше что произойдет не ведомо и это хорошо.

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

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

Добавим метод to XML всем объектам, а вот если мне нужен JSON, то это уже оберка берем XML и трансформируем в JSON, но сам объект об этом уже ничего не знает
Критика Егора. Комбинаторный взрыв:
когда в объекте было одно поле, а тут нам нужно добавить еще одно... и, если у нас 50 декораторов, у нас 50 изменений
В Hadoop классы в 3-4 тыс. строк о каком объектном программировании может идти речь, класс - это 50-70 строк, но не больше 200 ну еще раза в 2 раза больше на тестирование, а там их тысячи.

Думать нужно не со стороны БД а со стороны задачи. Вот у нас данные и мы хотим сделать по ним выборку, например - найти мужа и жену. Так может создать объект семья и уже этот объект будет обращаться к базе, а мы дальше работаем с этим объектом family целиком

MVC — это вторая большая ошибка в джаве. Но об этом позже.

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


Комментариев нет:

Отправить комментарий