Что такое "постоянство невежества"?

Неспособность сохранения обычно определяется как способность сохранять и извлекать стандартные объекты .NET(или POCOs, если вы действительно настаиваете на предоставлении им имени). И казалось бы, хорошо принятое определение стандартного объекта .NET:

"... обычные классы, где вы сосредоточены на проблемах бизнеса, не добавляя вещи по причинам, связанным с инфраструктурой..."

Тем не менее, я вижу, что люди, описывающие NHibernate как структуру, которая допускает незнание невежества, и тем не менее это структура, которая не может работать на каком-либо стандартном объекте .NET, только стандартные объекты .NET, которые придерживаются определенных требований к дизайну, например (источник):

Все классы должны иметь конструктор по умолчанию
Некоторые функции не работают, если классы не распечатаны, а все участники виртуальны.
Идентификация объекта не работает должным образом, если вы не злоупотребляете Equals/GetHashCode

(Кроме того: прежде чем кто-либо расстраивается, я не собираюсь выбирать NHibernate здесь, это просто часто цитируемый пример структуры, которая предположительно допускает незнание незнания. Я уверен, что аналогичные аргументы могут быть применены к другим ORM, которые заявите то же самое.)

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

В тех случаях, когда у меня возникают проблемы с определением "persistence ignorance" / "POCO", я не вижу, как это принципиально отличается от добавления атрибутов, таких как [Serializable] или [DataContract] или [XmlType] или любые другие аннотации, связанные с сохранением структуры, которые облегчают сохранение и извлечение объекта, использующего эту инфраструктуру.

Итак, что же такое "постоянство невежества"?

Ясно, что определение его как способного сохранять "обычные классы" является ошибкой, потому что NHibernate являются только обычными, поскольку не ссылаются на классы, специфичные для каркаса, тогда как они необычайны, поскольку они требуют необычных вариантов дизайна, таких как дефолт конструкторы и все виртуальные элементы и реализации Equals/GetHashCode на изменяемых типах.

Поэтому разумно ли говорить, что "незнание персистентности" истинно, когда объекты облегчают использование структуры персистентности (либо в дизайне и структуре, либо с использованием аннотаций, специфичных для структуры), но сами не выполняют никакой логики сохранения?

Ответ 1

Я бы сказал, что, как и большинство вещей, это скользящая шкала. Есть вещи, которые мы делаем, которые хотят иметь свойство настойчивости. На одном конце шкалы находится эта вещь, имеющая все кишки, зависимости и код, которые созданы на заказ, чтобы сохранить только одну вещь в своем конкретном ключе. На другом конце шкалы - это что-то, что просто волшебным образом происходит, без нашего использования гораздо больше, чем добавление маркера или установка свойства где-то, что заставляет эту вещь "просто упорствовать". Чтобы добраться до магической стороны шкалы, существуют рамки, руководящие принципы проектирования, соглашения и т.д., Которые помогают магии в происходящем. Я думаю, вы могли бы утверждать, что может быть создан инструмент, который имел бы меньше требований и ограничений, чем NHibernate, но преследовал ту же цель; что гипотетический инструмент будет дальше по нашему масштабу.

Я не знаю, что мне так нравится термин "постоянство невежества"; его действительно о том, что объект не осведомлен о реализации, резервном хранилище, кеше, что-то вроде того, что объект обычно знает о том, является ли он постоянным. Но это просто семантика.

Ответ 2

Я согласен с Mikeb - "незнание стойкости" является скользящей шкалой, а не истинной/ложной характеристикой данной ORM.

Мое определение истинного 100% PI было бы в том, что вы могли бы сохранить ЛЮБОЙ возможный класс POCO, независимо от того, как он был запутан и связан с другими классами, без какого-либо изменения класса.

Добавление полей идентификатора, украшение атрибутами, наследование из классов ORM, необходимость разработки классов, чтобы они хорошо отображались в базовых таблицах в RDB - все это уменьшало значение "PI score" ниже 100%.

Это говорит о том, что я выбрал использование Fluent NHibernate Automapping, потому что он, по-видимому, имеет самую высокую оценку PI любого из вариантов ORM, на которые я смотрел.

Ответ 3

Я не верю, что ваше понимание (или определение) "Persistence Ingorance" неверно.

Проблема реальная - проблема нечетких абстракций. Достаточно просто, существующая технология значительно упрощает реализацию очень истинного PI.

Ответ 4

Я согласен с вашим определением:

Поэтому разумно сказать, что "постоянство невежества" верно, когда объекты облегчают использование персистентности, но не выполнять любую логику сохранения сами?

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

Ответ 5

Постоянный неосведомленный класс, это класс, который не привязан к структуре постоянной.

То есть, класс не знает, что существует инфраструктура стойкости, она не наследуется от класса, который определен этой структурой, и не реализует интерфейс, который необходим для этой инфраструктуры прочности, чтобы работать.

Ответ 6

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

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

Ответ 7

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