реляционное отображение является настоятельной потребностью
Притом, что объектно- реляционное отображение является настоятельной потребностью современных корпоративных систем, как можно утверждать, что это трясина, из которой нет выхода? Здесь снова полезной аналогией является Вьетнам – в то время как ситуация в Южном Индокитае требовала реакции со стороны американцев, у администраций Кеннеди и Джонсона имелись различные варианты возможных действий, включая вариант реакции США на недавнее падение режима Сухарто в Малайзии, которая, честно говоря, просто отсутствовала. (Напомним, что Эйзенхауэр и Даллес не считали, что Южный Индокитай затрагивается «теорией домино»; их гораздо больше беспокоили Япония и Европа.)
Существует несколько возможных решений проблемы ОР-отображения, некоторые из которых требуют «глобальных» действий со стороны сообщества в целом, а некоторые более доступны для отдельных групп разработчиков.
1. Добровольный отказ. Разработчики просто полностью отказываются от объектов и возвращаются к модели программирования, не порождающей объектно-реляционной потери соответствия. Хотя это и неприятно говорить, но в некоторых сценариях объектно-ориентированный подход порождает больше накладных расходов, чем позволяет их сэкономить, и в этих случаях просто отсутствует возврат инвестиций (ROI), оправдывающий создание развитой объектной модели. (Более глубоко этот вопрос обсуждается в книге [Fowler].) Это полностью устраняет проблему, поскольку если нет объектов, то нет и несоответствия.
2. Полное принятие. Разработчики просто полностью отказываются от реляционного хранилища и используют модель хранения, которая соответствует видению мира, принятому в используемых ими языках. Проблему решают системы хранения объектов, такие как db4o, за счет непосредственного хранения объектов на диске, что устраняет многие (но не все) упомянутые выше проблемы. Например, в этом случае отсутствует «вторая схема», поскольку единственной используемой схемой являются определения самих объектов.
Хотя это может сильно шокировать администраторов баз данных, но во все более сервис-ориентированном мире, в котором воздерживаются от применения идеи непосредственного доступа к данным и взамен этого требуют, чтобы весь доступ к данным происходил через сервисные шлюзы, инкапсулируя механизм хранения данных от надоедливых глаз, становится совершенно реальным позволить разработчикам хранить данные в той форме, в которой их проще использовать именно им, а не DBA.
3. Отображение вручную. Разработчики просто соглашаются с тем, что проблема не настолько сложна, чтобы нельзя было ее решить вручную, и пишут прямой код для доступа к реляционным базам данных, обеспечивающий доступ к кортежам и позволяющий сохранять в базе данных данные объектов. Во многих случаях этот код может быть автоматически сгенерирован некоторым инструментальным средством на основе анализа метаданных базы данных, частично устраняя тем самым основу для критики этого подхода («слишком много кода нужно написать и сопровождать»).
4. Принятие ограничений ОР-отображения. Разработчики просто соглашаются с тем, что нет способа эффективно и просто решить проблему объектно-реляционного несоответствия и используют ОР-отображение для решения 85% проблемы (или 50%, или 95% в зависимости от ситуации), а в тех случаях, когда ОР-отображение может само породить проблемы, используют SQL и «примитивные» средства доступа в реляционным базам данных (такие как JDBC или ADO.NET). Однако у этого подхода имеется собственный риск, поскольку разработчики, использующие ОР-отображение, должны быть осведомлены о любом виде кэширования, производимом в используемом решении ОР-отображения, поскольку «примитивные» средства доступа к реляционной базе данных, очевидно, не будут использовать возможности этого кэширования.
5. Интеграция реляционных понятий с языками. Разработчики просто соглашаются с тем, что имеется проблема, которую следует решать на уровне языка, а не библиотеки или «оболочки».
В течение первого десятилетия работ над ОР-отображением усилия сосредотачивались на попытках подтащить объекты поближе к базе данных, чтобы разработчики могли фокусироваться на программировании в рамках одной парадигмы (в качестве которой выступали, конечно, объекты). Однако в следующие несколько лет интерес к «скриптовым» языкам с более сильной поддержкой множеств и списков, таким как Ruby, побудил идею о возможной пригодности другого решения: ввести реляционные понятия (которые, по своей сути, ориентированы на множества) в массовые языки программирования, облегчив тем самым устранение разрыва между «множествами» и «объектами». В этой области велось не очень много работ, в основном исследовательские проекты и/или языки, «выходящие за рамки общепринятого», но некоторые работы стали популярными в сообществе, например, функционально-объектные гибридные языки Scala
и F#, а также прямая интеграция с традиционными объектно-ориентированными языками, обеспечиваемая в проекте LINQ
компании Microsoft для C# и Visual Basic. К сожалению, одну из таких работ, а именно, стратегию SQL/J, постигла неудача. Даже в этом случае подход был ограниченным. В нем не предпринимались попытки внедрить множества в Java, а просто обеспечивались возможности препроцессорной обработки встроенных вызовов SQL и их трансляции в код JDBC.
6. Интеграция реляционных понятий с оболочками. Разработчики просто соглашаются с тем, что эта проблема является разрешимой, но только при изменении ее видения. Вместо того чтобы полагаться на язык или библиотеку, разрабатываемые для решения этой проблемы, разработчики принимают другое представление «объектов», более реляционное по своей природе, образуя прикладные оболочки, более близкие к реляционным конструкциям. Например, вместо создания класса Person, в котором данные экземпляров сохраняются непосредственно в полях объектов, разработчики создают класс Person, в котором данные его экземпляров сохраняются в экземпляре RowSet (Java) или DataSet (C#).
Этот экземпляр может собираться вместе с другими экземплярами RowSet/DataSet в блоки, которые могут легко использоваться для обновления базы данных или выбираться из базы данных и распаковываться в индивидуальные объекты.
Заметим, что порядок этого списка возможных решений не является существенным. Хотя одни решения являются более привлекательными, чем другие, решать, какое из них лучше, должны сами разработчики.
Подобно тому, как США, вероятно, могли бы достичь какого-нибудь «успеха» во Вьетнаме, если бы у правительства имелись ясная стратегия и более отчетливое понимание связи между обязательствами и результатами (если хотите, ROI), вероятно, можно справиться с проблемой объектно-реляционной потери соответствия на основе тщательного и разумного применения некоторой стратегии при полном понимании ее собственных ограничений. Разработчики должны стремится к полной «победе» там, где они могут победить, и не попадать на скользкую дорожку, пытаясь создавать решения, которые все дороже обходятся и все меньше приносят пользы. К сожалению, как показывает история войны во Вьетнаме, даже осознание опасностей скользкого пути часто бывает недостаточным для того, чтобы избежать увязания в трясине. Хуже того, эта трясина просто слишком привлекательна, чтобы обойти ее стороной, и разработчиков среди утесов продолжают соблазнять песни сирен, доносящиеся из разных компаний (включая Microsoft, IBM, Oracle, and Sun). Если вам хочется слушать эти песни, привяжитесь к мачте, но позвольте матросам грести.
