O/RM — это искусство установки квадратного штифта в круглое отверстие. Ваша база данных SQL основана на записях и отношениях, а объекты основаны на ООП. Могу я добавить, что ООП — это не более чем массовый психоз разработки программного обеспечения. Однако, игнорируя тот факт, что ООП в основном уничтожило все, что было хорошего в этом мире, O/RM по-прежнему является мусорной технологией, и вся идея «сопоставление объектов с записями базы данных» необходимо остановить. Потому что, в конце концов, O/RM — это как добавление повреждений мозга в вашу базу данных.

Например, использование шаблона репозитория делает очень заманчивым «спасти» ваши объекты. Игнорируя тот факт, что шаблон репозитория — это не более чем тонкий слой поверх CRUD, «экономия» ваши объекты приводят ко всевозможным трудным для решения проблемам. Например, представьте, что два человека одновременно редактируют одну и ту же запись. Давайте создадим класс, чтобы проиллюстрировать проблему.

class Customer
{
   string Name;
   string Address;
   string PhoneNo;
}
Войти в полноэкранный режим

Выйти из полноэкранного режима

Представьте, что Джон и Джейн одновременно работают над одним и тем же объектом. Джон обновляет Addressа Джейн обновляет PhoneNo. Они оба начинают работать над объектом одновременно, и поэтому «принес» объект из базы данных. Джон обновляет Address поле и клики «спасти». Джейн обновляет PhoneNo поле и клики «спасти». Поскольку Джейн получила объект клиента из «хранилище» до того, как Джон спас его, Address теперь возвращается к своему старому значению, значению, которое у него было до Джон обновил его. Это называется «состояние гонки». Потому что тот, кто сохранит объект последним «победы».

Условия гонки ORM

Чтобы решить вышеуказанную проблему, требуется то, что называется механизмами блокировки базы данных. SQL Server, например, решает эту проблему, позволяя пользователям создавать RowVersion столбцы на таблицах. Это называется «оптимистическая блокировка»и имеет тенденцию распространяться в GUI, приводя к дырявым абстракциям, требуя, чтобы разработчик был вынужден добавлять тонны мусорного кода в свой слой GUI, чтобы убедиться, что объекты действительно сохраняются, когда пользователь пытается их сохранить.

Существуют разные версии методов блокировки записей базы данных, но все они в основном являются мусором и требуют тонны кода мусора для распространения, вплоть до пользовательского интерфейса и человека, фактически редактирующего записи. Теперь у вас осталось программное обеспечение «решение» где может произойти сбой такой фундаментальной вещи, как обновление одного поля в одной записи базы данных, что заставит конечного пользователя «возвращаться» его изменения и «перезагрузить» исходный объект. 25% вашего кода теперь представляет собой безопасный охраняющий код, пытающийся помешать пользователю применить условия гонки к вашим данным, и этот мусорный код проникает из вашей базы данных через промежуточное программное обеспечение в уровень пользовательского интерфейса вашего приложения.

Игнорируя тот факт, что 98% разработчиков программного обеспечения даже не знают, как применить блокировку записей базы данных, и просто игнорируют ее, что приводит к мусорным данным в вашей базе данных. «идеально» кусок кода, обеспечивающий надежную защиту для таких сценариев, вы все равно получите мусорный код, где что-то столь фундаментальное, как изменение записи базы данных, может привести к тому, что у конечного пользователя появится модальная форма перед его лицом.

«Нам не удалось сохранить ваш объект. Вы хотите его принудительно загрузить, перезагрузить исходный объект или отменить?»

Большинство конечных пользователей даже не поняли бы, что здесь делать, и, вероятно, просто заболели бы, оставаясь дома до конца недели. быть спасен. Следовательно, использование O/RM на уровне вашей базы данных привело к тому, что конечный пользователь потерял полдня и не смог выполнять свою работу.

У нас есть слово для этого, и оно называется безумием!


Большая шутка

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

update customers set Address="xyz" where ...
Войти в полноэкранный режим

Выйти из полноэкранного режима

Затем представьте, что изменение Джейн привело к следующему.

update customers set PhoneNo = 'xyz' where ...
Войти в полноэкранный режим

Выйти из полноэкранного режима

Это буквально так просто. Теперь вы устранили все источники потенциальных условий гонки. Вам больше не нужна блокировка, и вы можете в основном SHIFT+DELETE 25% вашей кодовой базы, получая на порядки более безопасный код. Больше не надо «код синхронизации» в вашем слое пользовательского интерфейса, промежуточном программном обеспечении или базе данных.

Технический термин для этого «нарезка записи»и подразумевает выполнение частичные обновления записей. Однако это принципиально несовместимо с передовыми шаблонами проектирования O/RM, такими как Active Records, Repository Pattern и т. д., и т. д. и т. д. Я понимаю, что некоторые библиотеки O/RM реализуют этот метод нарезки, но тогда вы больше не используя вашу O/RM-библиотеку как O/RM-библиотеку, а скорее как печально реализованную замену SQL, и она становится ужасно реализованным функциональным языком программирования с неоптимальным уровнем сериализации базы данных, нарушающим все до единого «лучшая практика» вас учили, когда вы начали использовать библиотеки O/RM. Причины, по которым это невозможно реализовать в O/RM без нарушения лучших практик ООП, можно описать следующим образом…

Можно мне половину вашего предмета, пожалуйста?

В такой формулировке, как выше, это легко понять. ООП основан на классах и строго типизирован. Поставка «половина объекта» для ООП просто не имеет смысла и буквально невозможно. Следовательно, если вы хотите применить нарезку записей в своей O/RM, вы больше не используете свою O/RM как O/RM, а скорее что-то еще, и вы больше не используете свой язык ООП как ООП, а скорее как плохо реализованный функциональный язык программирования.

Если вы хотите увидеть, как мы решили эту проблему в АИСТвы можете посмотреть следующее видео, где я демонстрирую нарезку записи, полностью устраняющую проблему.


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