![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
ORM и системы типов
Понял, почему меня всегда так бесят сабжи, и почему всегда хочется "сделать по своему, с преферансом и гимназистками".
Вообще ORM это попытка скрестить ужа и ежа, т.е. гонять данные из одной системы типов в другую. Мало того, что это само по себе печально, так еще обычно и первая и вторая системы типов страдают унылостью, да еще и по разному в разных СУБД и языках программирования.
Т.е. нормальный ORM должен быть сделан либо на некоем общем подмножестве всего что есть(которое или пустое или настолько мелкое что ничего не даст сделать) или использовать достаточно мощную систему типов, которая бы позволила имитировать работу и СУБД и объектных языков и без особого напряга подстраиваться к ним.
А без этого получается имитация ужей методом сцепления ежей в списки или имитация ежей методом скручивания ужа в шар и протыкания иголками. А нужен ежеуж или ужеёж, с которым с одной стороны смогли бы совокуплятся в свое удовольствие ужи, а с другой - ежи.
PS: Да, хорошее было бы название для фреймворка - snagehog :)
Вообще ORM это попытка скрестить ужа и ежа, т.е. гонять данные из одной системы типов в другую. Мало того, что это само по себе печально, так еще обычно и первая и вторая системы типов страдают унылостью, да еще и по разному в разных СУБД и языках программирования.
Т.е. нормальный ORM должен быть сделан либо на некоем общем подмножестве всего что есть(которое или пустое или настолько мелкое что ничего не даст сделать) или использовать достаточно мощную систему типов, которая бы позволила имитировать работу и СУБД и объектных языков и без особого напряга подстраиваться к ним.
А без этого получается имитация ужей методом сцепления ежей в списки или имитация ежей методом скручивания ужа в шар и протыкания иголками. А нужен ежеуж или ужеёж, с которым с одной стороны смогли бы совокуплятся в свое удовольствие ужи, а с другой - ежи.
PS: Да, хорошее было бы название для фреймворка - snagehog :)
no subject
Что касается баз - та их можно вынести в отдельные DB Provider-ы, которые выдают наружу 4 метода для работы с данными (select, insert, update, delete), три для транзакций (begin, commit и rollback), и умеют мапить типы языка в базу (тобишь кто-то будет мапить Guid в uniqueidentifier, кто-то в char(64)). Плюс орм должен позволять навешивать на поля кастомные value converter, который позволяет сконвертировать тип поля в один из стандартных языковых и наоборот. Этого достаточно чтобы покрыть если не все, то хотябы большую часть различных ситуаций.
no subject
Вот чего реально не хватает в ADO - так это получения истинного типа селекта от сервера, т.е.
Параметр1 -> Параметр2 -> (Поле1,Тип,ИсточникДанных) -> (Поле2,Тип,ИсточникДанных) ..
В принципе, источник данных тут является частью типа, но система типов у SQL не настолько мощная, чтобы это описать.
Это все к чему - я обычно отчеты всякие описываю sql запросом, и если сервер возвращает такую информацию - практически весь гуй для отчета можно сгенерировать автоматически. А сейчас приходится к запросу еще дописывать вручную список параметров.
А насчет простых value converter - у типов в БД в некотором роде более сложная семантика, чем у жабо-дотнетовских - всякие там уникальные значения, внешние ключи, not null и check constraints. Поэтому обязательно вылезет какая-нибудь шиза, типа "проверить все ли правильно, можно только попытавшись сохранить в базу". А если база сидит за миддл-тиером это вырождается в тусование туда-сюда данных и сообщений об ошибках, что в отсутствие алгебраических типов данных сильно вгоняет в уныние.
no subject
Это, мы говорим об ORM или об ADO. Для orm ado это не более чем ещё один db provider.
> "проверить все ли правильно, можно только попытавшись сохранить в базу".
А это независимо от того пользуете ли вы орм, или напрямую инсерты делаете. Другое дело что всю эту кухню с проверками можно вынести на уровень того же орма, в каком-нить обработчике OnSaving плюс описать атрибутами чтобы орм правильную схему сгенерил.
no subject
no subject