Какое наиболее важное преимущество предоставляет персистентность объектов в приложении

Обновлено: 06.01.2025

Как показано на рис. 6.4, в общем можно выделить три класса приложений в соответствии со следующими категориями:

базовые транзакционные (или вспомогательные, обеспечивающие, обслуживающие – utility);
информационные (дающие преимущества);
инновационные (стратегические).

Рис. 6.4. Анализ ценности портфеля приложений на основе категоризации

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

Второй класс приложений – информационные (дающие преимущества). Это те приложения, которые обеспечивают информацию для учета, управления, контроля, получения отчетов, анализа, совместной работы (например, системы предоставления отчета о продажах, аналитические системы). Они улучшают деятельность организации. Примерами таких преимуществ от использования ИТ являются:

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

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

Наконец, в некоторых случаях использование ИТ может носить радикально новый, революционный характер с точки зрения влияния на функционирование организаций: способность кардинально изменить саму основу конкуренции и получения преимуществ. Это так называемые инновационные (стратегические или "пограничные") приложения. Именно они способны обеспечить конкурентные преимущества на рынке.

Примерами могут быть использование электронной торговли через Интернет или системы обслуживания кредитных карт банкоматами, которые в начале жизненного цикла этих технологий обеспечивали рост рынка компаниям, внедрившим их. В соответствии с кривыми развития (см. "ИТ-бюджеты и новые технологии" ), в начале внедрения таких приложений всегда есть много неясностей и рисков, но постепенно приложения становятся широко используемыми и достигают фазы, когда снова определяющими факторами становятся стоимость и надежность, т.е. они переходят в разряд базовых транзакционных. Основными проблемами при принятии решений по поводу таких приложений являются, с одной стороны, предрасположенность организации к внедрению инноваций, а с другой – наличие лидеров, способных мотивировать персонал и нацеливать его на успех, несмотря на то, что с внедрением таких приложений всегда есть риск неудач.

Преимущества описанного подхода к управлению портфелем приложений заключаются в простоте, ясности и чувстве уверенности, который он дает при принятии решений высшим руководителям организации, не являющимся ИТ-профессионалами.

Следует отметить еще одну категорию инвестиций в информационные технологии, которую необходимо, на самом деле, рассматривать в совокупности с тремя типами прикладных систем. Это – инфраструктура или технологическая архитектура, рассмотрению которой посвящен следующий раздел.

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

Рис. 6.5. Портфель ИТ и цели инвестиций в различные активы

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

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

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

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

Критически важное для предприятия в целом ( mission -critical). Приложение чрезвычайно важно для осуществления всей миссии компании, нарушения в работе приложения могут повлечь катастрофические последствия для бизнеса. Пример: система биллинга оператора мобильной связи или система управления движением в аэропорту.
Критически важное для бизнеса (business-critical). Приложение важно для поддержки отдельного направления бизнеса или обеспечивающего бизнес-процесса. Нарушения могут повлечь серьезные затруднения в бизнесе. Пример: система приема заказов через Интернет.
Вспомогательное (utility). Некритичное приложение, решающее частную, вспомогательную задачу. Пример: система резервирования помещений для переговоров.
Средства офисной автоматизации (office productivity). Это приложения, используемые для автоматизации повседневной работы. Типичный пример: офисные пакеты и средства подготовки презентаций.

Заметим, что для разных компаний одни и те же "стандартные" приложения, такие, как электронная почта или система приема заказов, могут относиться к различным уровням в данной классификации. Уже упомянутая выше система приема заказов через Интернет будет относиться к категории критически важного для предприятия в целом ( mission -critical) у магазина интернет-торговли книгами типа Amazon.com и к категории вспомогательного (utility) у крупной нефтяной компании. Кстати, наличие приложений "всех уровней" вовсе не обязательно! Например, в одном из встретившихся на практике случаев (для нефтедобывающей компании) выяснилось, что приложений уровня mission -critical там вообще нет! Как отметили сотрудники компании в анкетах, "в случае сбоя информационной системы, мы все отчеты считаем вручную и передаем в головную компанию по телефону. И такое запаздывание никак не влияет на результаты деятельности организации".

Мы не будем останавливаться на вопросах выбора конкретных приложений, таких как ERP-системы (КИС в отечественной интерпретации). Существенным аспектом является, однако, признание того факта, что возможностей отдельных, даже самых функционально полных промышленных систем, функционирующих в одиночку, недостаточно для покрытия всех потребностей предприятия. Интеграция различных приложений от разных производителей становится неизбежной необходимостью. А в этом случае вопросы оптимальной архитектуры приобретают особую важность.

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

Характерным примером может являться наблюдающаяся тенденция выделения типовой функциональности, такой как управление пользователями на уровне общесистемных сервисов. Если раньше разработчики приложений обязательно включали поддержку таких функций как регистрация пользователей, присваивание им отдельных прав доступа, задание паролей в свои приложения, или предлагали использовать стандартные средства используемой СУБД, то теперь практически все приложения позволяют использовать стандартные возможности, предоставляемые LDAP-серверами. Другими примерами такого рода являются поддержка электронной почты или документооборота (workflow) между пользователями в рамках одного приложения.

Идея, лежащая в основе персистентности, довольно проста. Предположим, что у вас есть приложение Python для управления списком задач на каждый день, и вы хотите запоминать объекты приложения (свои отдельные задачи) между использованием этой программы. Другими словами, вы желаете сохранять свои объекты на жестком диске, а затем их извлекать. Это и есть персистентность. Чтобы выполнить эту задачу, у вас есть несколько возможностей, каждая из них обладает своими достоинствами и недостатками.

Например, вы могли бы хранить данные своего объекта в какой-нибудь разновидности форматированного текстового файла, как CSV-файл. Или вы могли бы использовать реляционную базу данных, такую как Gadfly, MySQL, PostgreSQL или DB2. Эти файловые форматы хорошо определены, а Python обладает надежными интерфейсами для всех этих механизмов хранения.

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

Тем самым, для некоторых приложений применение реляционных баз данных, возможно, не является идеальным. В частности, из-за того, что реляционные базы данных не понимают объекты. Наоборот, они навязывают свои собственные системы типов и свои собственные модели данных для отношений (таблиц), каждая из которых содержит набор записей (рядов), состоящих из фиксированного числа статически типизированных полей (столбцов). Если объектная модель для вашего приложения не преобразовывается легко в реляционную модель, у вас будут определенные сложности при преобразовании своего объекта в записи и обратно. Эту проблему часто именуют несогласованностью интерфейсов (impedence-mismatch problem).

Персистентность объектов

Если вы хотите прозрачно сохранять объекты Python, не теряя их тождественность (identity), тип и так далее, вам потребуется некоторая форма сериализации - процесса, который превращает произвольно сложные объекты в текстовое или бинарное представление этих объектов. Таким же образом вы должны быть в состоянии восстановить эту сериализованную форму объекта обратно в объект, такой же, как и оригинал. На Python процесс сериализации называется консервированием (pickling), и вы можете законсервировать/восстановить свои объекты в/из строки, файла на диске или любого объекта, подобного файлу. Ниже мы детально рассмотрим консервирование.

Предположим, что вам нравится идея хранить все как объект, избегая накладных расходов на преобразование объектов в какую-либо разновидность хранения, не основанную на объектах. Файлы консервированных объектов (pickle files) дают такую возможность, но иногда вам потребуется что-нибудь более надежное и расширяемое, чем просто эти файлы. Например, само по себе консервирование не решает проблему наименования и обнаружения файлов консервированных объектов, как и не поддерживает одновременный доступ к перманентным объектам (persistent objects). За такими свойствами обратитесь к чему-нибудь вроде ZOBD, объектной базе данных Z для Python. ZOBD - это надежная многопользовательская объектно-ориентированная система баз данных, способная хранить и управлять произвольно сложными объектами Python, включая поддержку транзакций и управление параллельным доступом (чтобы скачать ZOBD, см. Ресурсы). Весьма интересно, что даже ZOBD полагается на Питоновские встроенные возможности сериализации, и, чтобы эффективно использовать ZOBD, у вас должно быть полное понимание консервирования.

Другой интересный подход к решению проблемы персистентности, первоначально реализованный на Java, называется Prevayler (ссылку на статью о Prevayler, опубликованную на developerWorks, см. в Ресурсах). Недавно группа программистов Python перенесла Prevayler на Python, и итог их трудов под названием PyPerSyst находится на SourceForge (ссылка на этот проект приведена в Ресурсах). Концепция Prevayler/PyPerSyst также строится на встроенных возможностях сериализации языков Java и Python. PyPerSyst держит все систему объектов в памяти и обеспечивает восстановление системы после аварии, время от времени консервируя на диск мгновенное состояние (snapshot) системы и поддерживая лог команд, которые могут повторно применяться к последнему снимку. Но, несмотря на то, что приложения, использующие PyPerSyst, по этой причине ограничены доступной памятью (RAM), преимущество состоит в том, что полностью загруженная в память система объектов, "родных" для языка, является чрезвычайно быстродействующей, и ее гораздо легче реализовать, чем ту, которая, подобно ZOBD, разрешает больше объектов, чем можно одновременно держать в памяти.

После того, как мы кратко коснулись различных способов хранения перманентных объектов, давайте детально рассмотрим процесс консервирования. Хотя основной интерес состоит в нахождении путей поддержания объектов Python без обязательного преобразования их в какой-нибудь другой формат, многие проблемы по-прежнему остались неразрешенными: как эффективно законсервировать и восстановить как простые, так и сложные объекты, включая экземпляры классов, определенных пользователем (custom classes); как поддерживать ссылки на объекты, в том числе циклические и рекурсивные; и как управлять изменениями описания класса, не создавая проблем с ранее законсервированными экземплярами. Все эти вопросы будут освещены ниже при рассмотрении Питоновских возможностей сериализации.

Суп из консервированного Python

Поддержка Питоновского консервирования проистекает из модуля pickle и его "собрата" сPickle . Второй модуль был написан на C, чтобы обеспечить лучшую производительность, и рекомендован для большинства приложений. Мы продолжим обсуждение pickle , но на самом деле в примерах будет использоваться сPickle . Поскольку большинство примеров будет показано из оболочки Python, давайте начнем с демонстрации того, как импортировать сPickle , сохраняя возможность ссылаться на него как pickle :

>>> import cPickle as pickle

После того, как мы импортировали этот модуль, давайте посмотрим на интерфейс модуля pickle . Модуль pickle предоставляет следующие пары функций: dumps(object) возвращает строку, содержащую объект в формате консервирования; loads(string) возвращает объект, находящийся в строке консервирования; dump(object, file) записывает объект в файл, который может быть как действительно физическим файлом, так и любым подобным файлу объектом, имеющим метод write() , который принимает один строчный аргумент; load(file) возвращает объект, содержащийся в файле консервированного объекта.

По умолчанию dumps() и dump() создают консервированные объекты, используя печатаемое представление ASCII. Обе функции имеют конечный факультативный аргумент, который, если True , устанавливает, что консервированные объекты будут создаваться с использованием более быстрого и меньшего по размеру бинарного представления. Функции loads() и load() автоматически определяют, находится ли консервированный объект в бинарном или текстовом формате.

Листинг 1 иллюстрирует интерактивную сессию с использованием описанных функций dumps() и loads() :

Листинг 1. Иллюстрация dumps()и loads()

Заметьте, что расшифровать текстовый формат консервированного объекта (text pickle format) не слишком сложно. Действительно, все задействованные условные обозначения документированы в модуле pickle . Также следует отметить, что для простых объектов, использующихся в нашем примере, использование бинарного формата консервированного объекта (binary pickle format) не привело к большому выигрышу в размере. Однако, в реальной системе со сложными объектами, при использовании бинарного формата вы получите заметное улучшение в размере и скорости.

Далее мы рассмотрим некоторые примеры, в которых dump() и load() используются для работы с файлами и объектами, подобными файлам. Эти функции действуют во многом аналогично dumps() и loads() , с которыми мы только что познакомились - с одной дополнительной возможностью - функция dump() позволяет выгружать несколько объектов один за другим в один и тот же файл. Последующие вызовы load() будут извлекать эти объекты в том же самом порядке. Листинг 2 демонстрирует эту возможность в действии:

Листинг 2. Пример dump() и load()

Мощь консервированных объектов

До сих пор освещались основы консервирования. В этом разделе мы рассмотрим некоторые нетривиальные проблемы, которые возникают при консервировании сложных объектов, включая экземпляры классов, определяемых пользователем. К счастью, Python, как вы увидите, довольно легко расправляется с такими задачами.

Переносимость

Листинг 3. Получение информации о поддерживаемых форматах

Многочисленные ссылки, один и тот же объект

Переменная на Python- это ссылка на объект. Вы можете иметь многочисленные переменные, ссылающиеся на один и тот же объект. Оказывается, что Python не испытывает никаких сложностей при поддержании этого поведения и с консервированными объектами, как следует из Листинга 4:

Листинг 4. Поддержание объектных ссылок

Циклические и рекурсивные ссылки

Поддержка объектных ссылок, которая была только что продемонстрирована, простирается и на циклические ссылки, когда два объекта содержат ссылки друг друга, и рекурсивные ссылки, когда объект содержит ссылку на самого себя. Следующие два листинга подчеркивают эту возможность. Давайте рассмотрим сначала рекурсивную ссылку:

Листинг 5. Рекурсивная ссылка

А теперь изучим циклическую ссылку:

Листинг 6. Циклическая ссылка

Заметьте, что мы получаем хоть и неприметно, но существенно различные результаты, если мы консервируем каждый объект отдельно, а не совместно внутри записи, как показано в Листинге 7:

Листинг 7. Консервирование по отдельности по сравнению с совместным консервированием внутри записи

Эквивалентны, но не всегда идентичны

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

Листинг 8. Восстановленные объекты как копии оригиналов

В то же время мы видели, что Python способен поддерживать ссылки между объектами, которые консервируются как блок (unit). Однако, мы также узнали, что раздельные вызовы dump() лишают Python способности поддерживать ссылки на объекты вне консервируемого блока. Python, наоборот, создает копию объекта, на который ссылаются, и хранит его с консервируемым элементом (item). Для приложения, которое консервирует и восстанавливает иерархию одиночного объекта, это не является проблемой. Но это то, о чем не стоит забывать в других ситуациях.

Также нужно отметить возможность, позволяющую консервированным объектам поддерживать ссылки друг на друга, если все они законсервированы в один и тот же файл. Модули pickle и cPickle предоставляют объекты Pickler (и соответствующий Unpickler ), которые могут отслеживать (track) объекты, которые уже были законсервированы. При использовании Pickler , разделяемые и циклические ссылки будут законсервированы по ссылке, а не по значению:

Листинг 9. Поддержание ссылок среди отдельно консервированных объектов

Неконсервируемые объекты

Некоторые типы объектов не могут быть законсервированы. Например, Python не может законсервировать файловый объект (или любой объект с ссылкой на файловый объект), потому что Python не может гарантировать, что он воссоздаст состояние файла при восстановлении. (Другие примеры настолько незначительны, что в данной статье о них не стоит упоминать.) Попытка законсервировать файловый объект приведет к следующей ошибке:

Листинг 10, Результат попытки законсервировать файловый объект

Экземпляры класса

Консервирование экземпляров класса требует немного больше внимания, чем консервирование типов простых объектов. Основная причина заключается в том, что Python консервирует данные экземпляра (обычно атрибут __dict__ ) и имя класса, но не код для класса. Когда Python восстанавливает экземпляр класса, он пытается импортировать модуль, содержащий описание класса, используя точные имена класса и модуля (включая любые префиксы пути к пакету) такими, какими они были во время консервирования экземпляра. Также заметьте, что описания класса должны располагаться на верхнем уровне модуля, что означает, что они не могут быть вложенными классами (классами, объявленными внутри других классов или функций).

Когда экземпляры класса восстанавливаются, обычно их метод __init__() не вызывается заново. Наоборот, Python создает родовой экземпляр класса, использует атрибуты экземпляра, которые были законсервированы, и устанавливает атрибут экземпляра __class__ так, чтобы он указывал на оригинальный класс.

Классы нового стиля (new-style class), появившиеся в Python 2.2, опираются на слегка отличный механизм восстановления. Несмотря на то, что результат этого процесса по существу такой же, как и с классами старого стиля, Python использует функцию _reconstructor() модуля copy_reg , чтобы восстановить экземпляры классов нового стиля.

Если вы хотите изменить поведение консервирования по умолчанию для экземпляров класса нового или старого стиля, вы можете описать специальные методы класса, а именно: __getstate__() и __setstate__ () - которые будут вызываться Python во время сохранения и восстановления информации о состоянии для экземпляров этого класса. В следующих разделах будут приведены некоторые примеры использования этих специальных методов.

Пока давайте рассмотрим экземпляр простого класса. Для начала мы создали модуль Python persist.py , в котором содержится следующее описание класса нового стиля:

Листинг 11. Описание класса нового стиля

Теперь мы можем законсервировать экземпляр Foo и изучить его представление:

Листинг 12. Консервирование экземпляра Foo

Как мы видим, и имя класса, Foo , и полностью квалифицированное имя модуля, Orbtech.examples.persist , хранятся в консервированном объекте. Если бы мы законсервировали этот экземпляр в файл и восстановили бы его позже (или на другой машине), Python попытался бы импортировать модуль Orbtech.examples.persist , и если бы не смог это сделать, возбудил бы исключение. Подобные ошибки случились бы, если бы мы переименовали класс, модуль или переместили модуль в другой каталог.

Ниже приведена ошибка, которую выдаст Python, если мы переименуем класс Foo , а затем попытаемся загрузить ранее законсервированный экземпляр Foo :

Листинг 13. Попытка загрузить законсервированный экземпляр переименованного класса Foo

Подобная ошибка возникнет, если мы переименуем модуль persist.py :

Листинг 14. Попытка загрузить консервированный экземпляр переименованного модуля persist.py

Ниже, в разделе Эволюция схемы, мы увидим, как управлять изменениями такого вида, не разрушая существующие консервированные объекты.

Специальные методы состояния

Ранее мы упоминали о том, что несколько типов объектов, как, например, файловые объекты, не могут быть законсервированы. Один из способов управлять атрибутами экземпляра, которые не являются консервируемыми объектами, - это воспользоваться специальными методами, доступными для модифицирования состояния экземпляра класса: __getstate__() и __setstate__() . Ниже приведен пример нашего класса , который мы модифицировали, чтобы управлять атрибутом файлового объекта:

Листинг 15. Обработка атрибутов неконсервируемого экземпляра

Когда экземпляр Foo будет законсервирован, Python законсервирует только те значения, которые возвращены в него при вызове метода __getstate__() этого экземпляра. Подобным образом во время восстановления Python передаст в метод __setstate__() этого экземпляра восстановленные значения в качестве аргумента. Внутри метода _setstate_() мы можем воссоздать файловый объект, опираясь на имя и информацию о положении, которые мы законсервировали, и присвоить файловый объект атрибуту logfile этого экземпляра.

Вопросы и ответы на собеседование по теме Hibernate Framework. Часть 1.

к списку вопросов раздела JEE

Вопросы

1. Что такое Hibernate Framework?
2. Какие важные преимущества дает использование Hibernate Framework?
3. Какие преимущества Hibernate над JDBC?
4. Назовите некоторые важные интерфейсы Hibernate.
5. Что такое конфигурационный файл Hibernate?
6. Что такое Hibernate mapping file?
7. Назовите некоторые важные аннотации, используемые для отображения в Hibernate.
8. Что вы знаете о Hibernate SessionFactory и как его сконфигурировать?
9. Является ли Hibernate SessionFactory потокобезопасным?
10. Как получить Hibernate Session и что это такое?
11. Является ли Hibernate Session потокобезопасным?
12. В чем разница между openSession и getCurrentSession?
13. Какая разница между методами Hibernate Session get() и load()?
14. Что вы знаете о кэшировании в Hibernate? Объясните понятие кэш первого уровня в Hibernate?
15. Как настроить кэш второго уровня в Hibernate с помощью EHCache?
16. Какие существуют различные состояния у entity bean?
17. Как используется вызов метода Hibernate Session merge()?
18. В чем разница между Hibernate save(), saveOrUpdate() и persist()?
19. Что произойдет, если будет отсутствовать конструктор без аргументов у Entity Bean?
20. В чем разница между sorted collection и ordered collection? Какая из них лучше?
21. Какие типы коллекций в Hibernate вы знаете?
22. Как реализованы Join’ы Hibernate?
23. Почему мы не должны делать Entity class как final?
24. Что вы знаете о HQL и какие его преимущества?
25. Что такое Query Cache в Hibernate?
26. Можем ли мы выполнить нативный запрос SQL (sql native) в Hibernate?
27. Назовите преимущества поддержки нативного sql в Hibernate.
28. Что такое Named SQL Query?
29. Какие преимущества Named SQL Query?
30. Расскажите о преимуществах использования Hibernate Criteria API.

31. Как логировать созданные Hibernate SQL запросы в лог-файлы?
32. Что вы знаете о Hibernate прокси и как это помогает в ленивой загрузке (lazy load)?
33. Как реализованы отношения в Hibernate?
34. Как управлять транзакциями с помощью Hibernate?
35. Что такое каскадные связи (обновления) и какие каскадные типы есть в Hibernate?
36. Как добавить логирование log4j в Hibernate приложение?
37. Как использовать JNDI DataSource сервера приложений с Hibernate Framework?
38. Как интегрировать Hibernate и Spring?
39. Что вы знаете о классе HibernateTemplate?
40. Как интегрировать Hibernate с Servlet или Struts2 веб приложением?
41. Какие паттерны применяются в Hibernate?
42. Расскажите о Hibernate Validator Framework.
43. Какие преимущества дает использование плагина Hibernate Tools Eclipse?
44. Best Practices в Hibernate.

Ответы

1. Что такое Hibernate Framework?

Hibernate — библиотека для языка программирования Java, предназначенная для решения задач объектно-реляционного отображения (object-relational mapping — ORM). Она представляет собой свободное программное обеспечение с открытым исходным кодом (open source), распространяемое на условиях GNU Lesser General Public License. Данная библиотека предоставляет легкий в использовании каркас (фреймворк) для отображения объектно-ориентированной модели данных в традиционные реляционные базы данных. Hibernate совместима с JSR-220/317 и предоставляет стандартные средства JPA.

2. Какие важные преимущества дает использование Hibernate Framework?

Hibernate является одним из самых востребованных ORM фреймворков для Java. И вот почему:

3. Какие преимущества Hibernate над JDBC?

Hibernate имеет ряд преимуществ перед JDBC API:

4. Назовите некоторые важные интерфейсы Hibernate.

5. Что такое конфигурационный файл Hibernate?

Файл конфигурации Hibernate содержит в себе данные о базе данных и необходим для инициализации SessionFactory. В .xml файле необходимо указать вендора базы данных или JNDI ресурсы, а так же информацию об используемом диалекте, что поможет hibernate выбрать режим работы с конкретной базой данных.

6. Что такое Hibernate mapping file?

Файл отображения (mapping file) используется для связи entity бинов и колонок в таблице базы данных. В случаях, когда не используются аннотации JPA, файл отображения .xml может быть полезен (например при использовании сторонних библиотек).

7. Назовите некоторые важные аннотации, используемые для отображения в Hibernate.

Hibernate поддерживает как аннотации из JPA, так и свои собственные, которые находятся в пакете org.hibernate.annotations. Наиболее важные аннотации JPA и Hibernate:

8. Что вы знаете о Hibernate SessionFactory и как его сконфигурировать?

SessionFactory является фабрикой классов и используется для получения объектов session. SessionFactory отвечает за считывание параметров конфигурации Hibernate и подключение к базе данных. Обычно в приложении имеется только один экземпляр SessionFactory и потоки, обслуживающие клиентские запросы, получают экземпляры session с помощью объекта SessionFactory. Внутреннее состояние SessionFactory неизменно (immutable). Internal state (внутреннее состояние) включает в себя все метаданные об Object/ Relational Mapping и задается при создании SessionFactory.

SessionFactory также предоставляет методы для получения метаданных класса и статистики, вроде данных о втором уровне кэша, выполняемых запросах и т.д.

9. Является ли Hibernate SessionFactory потокобезопасным?

Т.к. объект SessionFactory immutable (неизменяемый), то да, он потокобезопасный. Множество потоков может обращаться к одному объекту одновременно.

10. Как получить Hibernate Session и что это такое?

Объект Hibernate Session является связью между кодом java приложения и hibernate. Это основной интерфейс для выполнения операций с базой данных. Жизненный цикл объекта session связан с началом и окончанием транзакции. Этот объект предоставляет методы для CRUD ( create , read , update , delete ) операций для объекта персистентности. С помощью этого экземпляра можно выполнять HQL, SQL запросы и задавать критерии выборки.

11. Является ли Hibernate Session потокобезопасным?

Объект Hibernate Session не является потокобезопасным. Каждый поток должен иметь свой собственный объект Session и закрывать его по окончанию.

12. В чем разница между openSession и getCurrentSession?

Hibernate SessionFactory getCurrentSession() возвращает сессию, связанную с контекстом. Но для того, чтобы это работало, нам нужно настроить его в конфигурационном файле hibernate. Так как этот объект session связан с контекстом hibernate, то отпадает необходимость к его закрытию. Объект session закрывается вместе с закрытием SessionFactory .

Я googled и узнал, что слой persistence используется для хранения и извлечения данных, как правило, из базы данных.

Может кто-нибудь объяснить подробно?

спросил(а) 2013-04-15T16:10:00+04:00 8 лет, 7 месяцев назад

причина для создания DAL (уровня доступа к данным) или любого другого промежуточного уровня между движком базы данных и логикой Business/Application заключается в том, что добавив этот слой в промежуток между вами, вы изолируете остальные/верхние уровни вашего приложения из конкретного механизма/технологии базы данных, которые вы используете прямо сейчас.

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

ответил(а) 2013-04-15T16:18:00+04:00 8 лет, 7 месяцев назад

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

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

Уровень данных должен быть записан для конкретной базы данных. Поэтому, если вы используете MySQL для доступа ко всем своим данным, вы будете писать DataLayer для этого.

Если в какой-то момент вы решите перейти на MongoDB, вместо этого перепишите все ваше приложение. Вы можете переписать только части доступа к данным, чтобы получить данные от MongoDB. Поскольку бизнес-логика не заботится о том, как вы получаете данные, только то, что вы делаете, оно и уровень Presenation могут оставаться неповрежденными.

Надеюсь, что это поможет.

ответил(а) 2013-04-15T16:16:00+04:00 8 лет, 7 месяцев назад

В очень простых терминах уровень сохранения - это способ использования SAVE и RETRIEVE, который использует ваше приложение.

Простой пример: у вас есть класс, который представляет человека (имя, возраст и пол). Пока приложение работает, оно сохраняется в памяти. Но, скажем, вам нужна эта информация, если вы снова закрываете и открываете приложение. Ну, вам нужен способ СОХРАНИТЬ этот человек, а затем снова RETRIEVE. В этом месте появится слой персистентности и напишет ваш человек где-то "постоянным".

Это может быть база данных, плоский файл, реестр в зависимости от срока службы и требований и т.д.

В ваших уровнях персистентности вы выполните операции CRUD (Create, Read, Update, Delete). Часто против базы данных, чтобы вы Создать новый человек (Fred Bloggs). Скажем, что они меняют свое имя, другой пользователь вашей системы может прочитать запись и перейти на Fred Miggins и Обновить базу данных. Затем этот клиент покидает страну, чтобы вы Удалить.

Читайте также: