Охарактеризовать основные слои веб приложения на JAVA. (JPA, Entity bean, JDBC, DAO, SessionBean, Facade)
JPA – это технология, обеспечивающая объектно-реляционное отображение простых JAVA объектов и предоставляющая API для сохранения, получения и управления такими объектами. JPA – это спецификация (документ, утвержденный как стандарт, описывающий все аспекты технологии), часть EJB3 спецификации.
Сам JPA не умеет ни сохранять, ни управлять объектами, JPA только определяет правила игры: как что-то будет действовать. JPA также определяет интерфейсы, которые должны будут быть реализованы провайдерами. Плюс к этому JPA определяет правила о том, как должны описываться метаданные отображения и о том, как должны работать провайдеры. Дальше, каждый провайдер, реализуя JPA определяет получение, сохранение и управление объектами. У каждого провайдера реализация разная.
Entity bean представляет собой компоненту, работающую с постоянной (persistent) информацией, хранящейся, например, в базе данных. Entity beans ассоциируются с элементами баз данных и могут быть доступны одновременно нескольким пользователям. Так как информация в базе данных является постоянной, то и entity beans живут постоянно, "выживая", тем самым, после сбоев сервера (когда сервер восстанавливается после сбоя, он может восстановить "бин" из базы данных). Например, entity bean может представлять собой строку какой-нибудь таблицы из базы данных, или даже результат операции SELECT. В объектно-ориентированных базах данных, entity bean может представлять собой отдельный объект, со всеми его атрибутами и связями.
JDBC (англ. Java DataBase Connectivity — соединение с базами данных на Java) — платформенно-независимый промышленный стандарт взаимодействия Java-приложений с различными СУБД, реализованный в виде пакета java.sql, входящего в состав Java SE. JDBC основан на концепции так называемых драйверов, позволяющих получать соединение с базой данных по специально описанному URL. Драйверы могут загружаться динамически (во время работы программы). Загрузившись, драйвер сам регистрирует себя и вызывается автоматически, когда программа требует URL, содержащий протокол, за который драйвер отвечает. JDBC, важно отметить, поддерживает работу не только с SQL совместимыми СУБД, но также и с практически любыми данными табличного типа.
Шаблон DAO должен быть хорошо известен любому разработчику корпоративных Java-приложений. Реализации шаблона значительно отличаются между собой, однако давайте проясним положения, лежащие в основе реализации DAO, представленной в данной статье:
Весь доступ к базе данных в системе производится через DAO для инкапсуляции.
Каждый экземпляр DAO отвечает за один первичный доменный объект или сущность. Если доменный объект имеет независимый цикл жизни, он должен иметь свой собственный DAO.DAO отвечает за операции создания, чтения (по первичному ключу), обновления и удаления (то есть, CRUD (create, read, update, delete)) доменного объекта. DAO может разрешать запросы, основанные на критерии, отличном от первичного ключа. Я ссылаюсь на такие методы как finder или finders . Метод finder обычно возвращает коллекцию доменных объектов, за которые отвечает DAO.DAO не занимается обработкой транзакций, сессий или соединений. Это делается вне DAO для обеспечения гибкости.
Session bean представляет собой EJB-компоненту, связанную с одним клиентом. "Бины" этого типа, как правило, имеют ограниченный срок жизни (хотя это и не обязательно), и редко участвуют в транзакциях. В частности, они обычно не восстанавливаются после сбоя сервера. В качестве примера session bean можно взять "бин", который живет в веб-сервере и динамически создает HTML-страницы клиенту, при этом следя за тем, какая именно страница загружена у клиента. Когда же пользователь покидает вэб-узел, или по истечении некоторого времени, session bean уничтожается. Несмотря на то, что в процессе своей работы, session bean мог сохранять некоторую информацию в базе данных, его предназачение заключается все-таки не в отображении состояния или в работе с "вечными объектами", а просто в выполнении некоторых функций на стороне сервера от имени одного клиента.
Паттерн Facade (Фасад) встречается достаточно часто и соответственно заслуживает внимания.Нужен он вот для чего. При написании кода программисту приходится использовать различные third-party библиотеки. Часто API библиотек довольно абстрактное. Некоторые методы классов могут быть вообще не нужны или содержать параметры, которые не существенны для решения конкретной задачи. Далее, для получения результата могут понадобиться длинные цепочки вызовов методов или же сам результат будет не совсем в подходящем виде. Все эти проблемы можно решить с помощью паттерна Facade. Класс, реализующий этот паттерн, является неким интерфейсом, сочетающим в себе только необходимую функциональность в удобном для пользователя виде. Так можно скрыть реализацию сложных частей кода, уменьшить количество зависимостей от внешней библиотеки и, наконец, работать со множеством объектов через прозрачный и удобный интерфейс. Это, в свою очередь, гарантирует более качественную и простую поддержку всей системы.