Читаем Изучаем Java EE 7 полностью

··············integration-test

··············verify

············

··········

········

······

····

··

Чтобы скомпилировать классы, откройте командную строку в корневом каталоге, содержащем файл pom.xml, и введите следующую команду Maven:

$ mvn compile

Чтобы выполнить интеграционные тесты с плагином Maven Failsafe, введите в командную строку:

$ mvn integration-test

Резюме

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

В этой главе было показано, что ограничение состоит из аннотации и отдельного класса, реализующего логику валидации. При дальнейшей работе можно агрегировать имеющиеся ограничения для создания новых или переиспользовать уже имеющиеся. Спецификация Bean Validation содержит несколько встроенных ограничений, хотя, к сожалению, некоторых ограничений в ней сильно не хватает (@Email, @URL, @CreditCard).

В первой версии спецификации Bean Validation можно было валидировать только методы и атрибуты. Так обеспечивалось более качественное предметно-ориентированное проектирование, при котором неглубокая доменная валидация помещалась в сам POJO, что позволяло избегать антипаттерна «анемичный объект». В версии Bean Validation 1.1 появилась валидация конструкторов, параметров методов и возвращаемых значений. В настоящее время можно выполнять валидацию предусловий и постусловий, что приближает нас к проектированию по соглашениям.

Из следующих глав вы узнаете, как валидация компонентов интегрирована в Java EE, какую роль в этом играют JPA и JSF и как ее можно использовать в большинстве спецификаций.

Глава 4. Java Persistence API

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

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

Основная идея объектно-реляционного отображения (Object-Relational Mapping — ORM) заключается в объединении миров баз данных и объектов. Это подразумевает делегирование доступа к реляционным базам данных внешним инструментам или фреймворкам, которые, в свою очередь, обеспечивают объектно-ориентированное представление реляционных данных, и наоборот. Инструменты отображения предусматривают двунаправленное соответствие между базой данных и объектами. Несколько фреймворков обеспечивают это, например Hibernate, TopLink и Java Data Objects (JDO), а Java Persistence API (JPA) является предпочтительной технологией и частью Java EE 7.

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

Понятие сущностей

Перейти на страницу:

Похожие книги

C# 4.0: полное руководство
C# 4.0: полное руководство

В этом полном руководстве по C# 4.0 - языку программирования, разработанному специально для среды .NET, - детально рассмотрены все основные средства языка: типы данных, операторы, управляющие операторы, классы, интерфейсы, методы, делегаты, индексаторы, события, указатели, обобщения, коллекции, основные библиотеки классов, средства многопоточного программирования и директивы препроцессора. Подробно описаны новые возможности C#, в том числе PLINQ, библиотека TPL, динамический тип данных, а также именованные и необязательные аргументы. Это справочное пособие снабжено массой полезных советов авторитетного автора и сотнями примеров программ с комментариями, благодаря которым они становятся понятными любому читателю независимо от уровня его подготовки. Книга рассчитана на широкий круг читателей, интересующихся программированием на C#.Введите сюда краткую аннотацию

Герберт Шилдт

Программирование, программы, базы данных
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Нил Форд , Билл де Ора , Майкл Хайгард

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT