Что такое точно “незнание персистентности”?
Незнание персистентности обычно определяется как способность сохранить и получить стандартные объекты.NET (или POCOs, если Вы действительно настаиваете на том, чтобы давать им имя). И по-видимому хорошо принятое определение стандартного объекта.NET:
"... обычные классы, где Вы фокусируетесь на бизнес-проблеме под рукой, не добавляя материал по связанным с инфраструктурой причинам..."
Однако я вижу, что люди описывают NHibernate как платформу, которая позволяет незнание персистентности, и все же это - платформа, которая не может работать ни над каким стандартным объектом.NET, только стандартные объекты.NET, которые придерживаются конкретных конструктивных требований, например (источник):
- Все классы должны иметь конструктора по умолчанию
- Некоторые функции не работают, если классы не распечатываются, и все участники виртуальные
- Объектные идентификационные данные не работают правильно, если Вы не злоупотребляете Equals/GetHashCode
(В стороне: Прежде чем кто-либо будет расстроен, я не означаю выбирать NHibernate здесь, это - просто часто заключаемый в кавычки пример платформы, которая, предположительно, разрешает незнание персистентности. Я уверен, что подобные аргументы могли быть применены к другим ORMs, которые требуют того же.)
Теперь, хотя класс сам по себе не имеет никаких атрибутов persistence-framework-specific или базовых классов и т.д., мне это не действительно "персистентность, неосведомленная", потому что это должно следовать за рядом руководства по проектированию для упрощения использования выбранной платформой персистентности. Необходимо разработать и реализовать класс с требованиями платформы персистентности в памяти; если Вы незнакомы с ним, класс не может работать с ним.
Где я испытываю затруднения из-за определения "незнания персистентности" / "ПОСТЕПЕННО" то, что я не вижу, как, концептуально, это действительно несколько отличается от добавления атрибутов такой как [Serializable] или [DataContract] или [XmlType] или любые другие persistence-framework-specific аннотации, которые упрощают персистентность и извлечение объекта с помощью той платформы.
Так, что такое точно "незнание персистентности"?
Очевидно определением его как способность сохранить "обычные классы" является ошибка, потому что NHibernate только обычны, поскольку, не ссылаясь на определенные для платформы классы, тогда как они экстраординарны, поскольку они требуют необычных проектных решений, таких как конструкторы по умолчанию и все-виртуальные участники и реализации Equals/GetHashCode на изменяемых типах.
Поэтому разумно сказать, что "незнание персистентности" верно, когда объекты упрощают использование платформы персистентности (или в дизайне и структуре или при помощи определенных для платформы аннотаций), но не выполняют логики персистентности самих?
7 ответов
Я бы утверждал, что, как и большинство вещей, это скользящая шкала. Есть вещи, которые мы делаем, которые хотят иметь свойство настойчивости. На одном конце шкалы находится эта вещь, обладающая всеми кишками, зависимостями и кодом, который настраивается на сохранение именно этой вещи. На другом конце шкалы есть нечто, что просто волшебным образом происходит, и все это без того, чтобы мы не делали ничего большего, кроме добавления маркера или установки свойства где-то, что заставляет эту вещь 'просто сохраняться'. Чтобы добраться до волшебной стороны шкалы, существуют рамки, руководства по проектированию, конвенции и т.д., которые помогают волшебству происходить. Я думаю, что можно утверждать, что можно создать инструмент, который имеет меньше требований и ограничений, чем NHibernate, но преследует ту же самую цель; этот гипотетический инструмент будет дальше по шкале.
Я не знаю, что мне так нравится термин "упорное невежество"; на самом деле он говорит о том, что объект не знает о реализации, хранилище подложек, кэш, что-то в этом роде - объект, как правило, знает, является ли он упорным или нет. Но это всего лишь семантика.
Я не верю, что ваше понимание (или определение) "Непостижимости" неверно.
Реальная проблема заключается в утечке абстракций . Проще говоря, существующая технология затрудняет реализацию настоящего ПИ очень .
.Я согласен с Майкбом - "невежество о преследовании" - это скользящая шкала, а не истинное/ложное свойство данного ORM.
Моим определением истинного 100% ПИ было бы то, что вы могли бы сохранить ЛЮБОЙ возможный класс POCO, независимо от того, насколько он запутан и связан с другими классами, не изменяя при этом класс каким-либо иным образом.
Добавление полей ID, декорирование атрибутами, наследование от классов ORM, необходимость проектировать свои классы таким образом, чтобы они хорошо соответствовали базовым таблицам в RDB - все это уменьшает "оценку PI" ниже 100%.
Тем не менее, я решил использовать Fluent NHibernate Automapping, потому что, похоже, у него самая высокая оценка PI среди всех рассмотренных мною вариантов ORM.
.Я согласен с вашим определением:
Поэтому разумно ли говорить, что "упорное невежество" - это правда, когда объекты облегчают использование рамки упорства, но не выполнять любую логику настойчивости себя?
Код (в отличие от атрибутов) в ваших классах не имеет свойств, присущих персистентности. Для персистентности могут потребоваться конструкторы по умолчанию, но у них нет кода, который на самом деле делает персистентность. Уровень родства можно значительно изменить, можно использовать различные базы данных, а бизнес-логика останется неизменной
.Класс стойкого невежества - это класс, который не привязан к рамкам стойкости.
То есть, класс не имеет абсолютно никакого представления о том, что существует рамочная программа для предотвращения преследования, он не наследует от класса, который определен этой рамочной программой, и не реализует интерфейс, который необходим для этой рамочной программы для предотвращения преследования, чтобы работать.
.Хотя могут существовать определенные незначительные ограничения, которые требуются для любой системы с постоянным усилением, тем не менее, постоянное усиление все же остается на своем месте.
Хотя класс в вашей доменной модели (прозрачно сохраняемый с помощью NHibernate) должен иметь конструктор нулевых инструментов, чтобы его можно было построить "динамически", от него не требуется наличие определенного базового класса, продиктованного фреймворком, а также не требуется наличие определенных методов, продиктованных фреймворком, или их переопределение
.На мой взгляд, "упорное невежество" является свойством вашей модели (доменной модели, бизнес-модели или как ее там вы можете назвать). Модель является persistence ignorance, поскольку она извлекает экземпляры содержащихся в ней сущностей с помощью абстракций (иногда называемых репозиториями). Эти абстракции могут быть реализованы непосредственно с помощью ORM, но, как вы сами утверждаете, иногда это может добавлять требования к объектам, которые естественным образом не принадлежат вашей модели. Поэтому я бы не сказал, что модель, которая придерживается некоторых требований конкретного ORM, на 100% невежественна.
.