http://grandruru.blogspot.tw/2016/02/delphi-orm-generator.html
Попробывал, нашел баг, вышел апдейт. Должны были починить. Сама идея мне нравится, как нибудь распишу подробнее свое виденее.
Написан под Windows 10.
Как его запустить(и вообще возможно ли) без Windows Store, я пока не знаю.
Попробывал, нашел баг, вышел апдейт. Должны были починить. Сама идея мне нравится, как нибудь распишу подробнее свое виденее.
Написан под Windows 10.
Как его запустить(и вообще возможно ли) без Windows Store, я пока не знаю.
Идее уже лет сто.
ОтветитьУдалить> Сама идея мне нравится, как нибудь распишу подробнее свое виденее.
ОтветитьУдалить>
Обозначьте хотя бы в тезисах.
[1] ПМСМ ORM конструктивен для весьма узкого круга задач.
Основные его достоинства вижу в следующем:
1. Какой-никакой контроль типов. Таблицы отображаются в классы, соответственно, поля таблиц - в поля классов. При работе с полями объектов компилятор помогает с контролем типов.
2. В простейших случаях - работа с записью или с её связями (без специфики) SQL ненужен. Связи могут быть представлены в виде списочных свойств в классах/объектах-представлениях таблиц.
3. В ряде случаев (но не в данном, как я понял), ORM содержит средства, "упрощающие" создание простых запросов, опять же, не обращаясь к SQL.
4. Следствие предыдущих пунктов: минимизация применения SQL, что ведёт к большей независимости от определённого диалекта SQL/СУБД.
[2] Минусы ORM (любой) вижу в том, что:
1. От SQL ORM полноценно не изолирует. В результате появляется эклектика (SQL и ORM-style запросы), и зависимость от платформы (SQL/СУБД) сохраняется.
2. Применение ORM подталкивает к неэффективному использованию СУБД. Запросы далеко не всегда тривиальны. SQL, построенный средствами ORM часто заметно хуже, чем если бы SQL был создан вручную. Это критично для нагруженных приложений.
3. "Сахар" (пп.1-4) вполне достижим иными средствами. пп.2-4, например, посредством DAL.
Суммируя, конструктивным в ORM вижу только [1].1, но результат его реализации язык не повернётся назвать ORM :-)