Что такое «Невежество настойчивость»?

Question

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

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

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

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

(В стороне: прежде чем кто -то расстроится, я не хочу выбирать здесь nhibernate, это просто часто цитируемый пример структуры, которая предположительно позволяет устойчивов невежество. Я уверен ..

Теперь, хотя класс сам по себе не имеет каких-либо каких-либо атрибутов, специфичных для стойкости или базовых классов и т. Д., Для меня это на самом деле не «не знает настойчиво способствовать Используйте выбранную структуру настойчивости. Вы должны спроектировать и реализовать класс с учетом требований структуры настойчивости; Если вы не знаете об этом, класс может не работать с ним.

Где у меня проблемы с определением «Невероятность настойчивости»/«Поко», я не вижу, как, концептуально, это действительно отличается от добавления атрибутов, таких как [Serializable] или же [DataContract] или же [XmlType] или любые другие аннотации, специфичные для кадров способствовать Постоянство и поиск сущности, используя эту структуру.

Итак, что именно такое «Невежество настойчивость»?

Очевидно, что его определение как способное сохранять «обычные классы», является ошибкой, потому что Nhibernate-это лишь обычные, поскольку не ссылаются на основу классов, в то время как они необычайны, поскольку они требуют необычного выбора дизайна, таких как конструкторы по умолчанию и все такое -Витвированные члены и равенство/gethashcode реализации на изменяемых типах.

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

Answer 1

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

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

Answer 2

Я не верю, что ваше понимание (или определение) «настойчивости негастной» - это неправильно.

А настоящий проблема - это проблема Протекающие абстракции. Анкет Проще говоря, существующая технология делает ее очень Трудно внедрить истинный пи.

Answer 3

Я согласен с Mikeb - «Невежество на стойкость» - это скользящая шкала, а не истинное/ложное свойство данного ORM.

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

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

Тем не менее, я решил использовать автоматическую автоматизацию Fluent Nhibernate, потому что, похоже, у нее самый высокий балл PI из всех вариантов ORM, на которые я смотрел.

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

В то время как класс в вашей доменной модели (прозрачно сохранялся с nhibernate) должен иметь конструктор без аргументов, чтобы его можно было построить «динамически», не требуется, чтобы определенный базовый класс продиктовал структурой и не требуется, чтобы иметь или переопределить определенные методы, определенные структурой.

Answer 7

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

Answer 8

Вы можете реализовать невежество Persistence, используя класс для домена или вашего приложения и класса Poco в стойкости, когда вы собираетесь сохранить в своем классе постоянства и используйте объект настойчивости для хранения с помощью Nhibernate o Другие рамки

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

Эти правила структуры настойчивости могут быть в вашем классе настойчивости.