gof, класс jpa, компоненты Angular | GoF-паттерны Описаны в книге 1994 г. «Design Patterns: Elements of Reusable Object-Oriented Software» («Приёмы объектно-ориентированного проектирования. Паттерны проектирования»). В книге описаны 23 классических шаблона проектирования. Виды: 1) Порождающие - имеют дело с механизмами создания объекта и пытаются создать объекты в порядке, подходящем к ситуации. ● Abstract Factory — Абстрактная фабрика. ● Builder — Строитель. ● Factory Method — Фабричный метод. ● Prototype — Прототип. ● Singleton — Одиночка (Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа. Можно пользоваться экземпляром класса (в отличие от статических методов).) 2) Структурные - отвечают за построение удобных в поддержке иерархий классов ● Adapter — Адаптер. ● Bridge — Мост. ● Composite — Компоновщик. ● Decorator — Декоратор. — позволяет динамически подключать дополнительное поведение к объекту без использования наследования. ● Facade — Фасад. ● Flyweight — Приспособленец. ● Proxy — Заместитель. 3) Поведенческие - определяют алгоритмы и способы реализации взаимодействия различных объектов и классов ● Chain of responsibility — Цепочка обязанностей. ● Command — Команда. (команда передаётся с помощью специального объекта, который заключает в себе само действие (т. е. логику) и его параметры.) ● Interpreter — Интерпретатор. ● Iterator — Итератор. ● Mediator — Посредник. ● Memento — Хранитель. ● Observer — Наблюдатель. ● State — Состояние. ● Strategy — Стратегия. ● Template — Шаблонный метод. ● Visitor — Посетитель. Класс jpa Entity (Сущность) — POJO-класс, связанный с БД с помощью аннотации (@Entity) или через XML. К такому классу предъявляются следующие требования:
При этом entity может:
Entities могут быть связаны друг с другом (один-к-одному, один-ко-многим, многие-к-одному и многие-ко-многим) JPA указывает что она может работать как с свойствами классов (property), оформленные в стиле JavaBeans, либо с полями (field), то есть переменными класса. Оба типа элементов Entity класса называются атрибутами Entity класса. Компоненты Angular Одним из ключевых элементов приложения являются компоненты. Компонент управляет отображением представления на экране. Компонент:
Сам класс компонента здесь относительно небольшой:
Чтобы класс мог использоваться в других модулях, он определяется с ключевым словом export. В самом же классе определена лишь одна переменная, которая в качестве значения хранит некоторую строку. Декоратор @Component позволяет идентифицировать класс как компонент. Если бы мы не применили декоратор @Component к классу AppComponent, то класс AppComponent компонентом бы не считался. Декоратор @Component в качестве параметра принимает объект с конфигурацией, которая указывает фреймворку, как работать с компонентом и его представлением. С помощью свойства template шаблон представляет кусок разметки HTML с вкраплениями кода Angular. Фактически шаблон это и есть представление, которое увидит пользователь при работе с приложением. Каждый компонент должен иметь один шаблон. Можно вынести шаблон во внешний файл с разметкой html, а для его подключения использовать свойство templateUrl. Шаблон может быть однострочным или многострочным. Если шаблон многострочный, то он заключается в косые кавычки (`), которые стоит отличать от стандартных одинарных кавычек ('). Также в примере выше устанавливается свойство selector, которое определяет селектор CSS. В элемент с этим селектором Angular будет добавлять представление компонента. Например, в примере выше селектор имеет значение my-app. Соответственно если html-страница содержит элемент <my-app></my-app>, то именно этот элемент будет использоваться для рендеринга представления компонента. |
React router, navigation rule jsf, model1 vs model2(MVC) | React router (примеры на react-router-dom ) !!!!!!!!!! react-router-dom экспортирует из react-router все функции Ключевым звеном в работе маршрутизации являются модули react-router и react-router-dom, которые содержат основной функционал по работе с маршрутизацией. В начале для работы с маршрутами также получаем ряд объектов, которые потребуются для определения маршрутов:
Здесь определены три объекта из модуля react-router-dom. Router определяет набор маршрутов и, когда к приложению, приходит запрос, то Router выполняет сопоставление запроса с маршрутами. И если какой-то маршрут совпадает с URL запроса, то этот маршрут выбирается для обработки запроса. Для браузерных проектов есть BrowserRouter и HashRouter компоненты. BrowserRouter — следует использовать когда вы обрабатываете на сервере динамические запросы, а HashRouter используйте когда у вас статический веб сайт. И также для выбора маршрута определен объект Switch. Он позволяет выбрать первый попавшийся маршрут и его использовать для обработки. Без этого объекта Router может использовать для обработки одного запроса теоретически несколько маршрутов, если они соответствуют строке запроса. Каждый маршрут представляет объект Route. Он имеет ряд атрибутов. В частности, здесь для маршрута устанавливаются два атрибута:
В данном случае один маршрут выступает в качестве корневого, сопоставляется с адресом "/" и обрабатывается компонентом Main:
Квалификатор exact допускает только точное совпадение маршрута со строкой запроса. Например, строка запроса может представлять путь "/" или путь "/about", и эти пути будут соответствовать маршруту с шаблоном адреса "/". То есть маршруту, который обрабатывается компонентом Main. Но слово exact позволяет рассматривать точное совпадение, то есть когда шаблону "/" соответствует только строка запроса "/". Второй маршрут будет сопоставляться с адресом "/about", а обрабатываться он будет компонентом About.
Особо следует выделить третий маршрут:
Этот маршрут будет сопоставляться со всеми адресами URL, которые не соответствуют предыдущим маршрутам. И он будет обрабатываться компонентом NotFound. Таким образом мы можем задать обработку при обращении к несуществующим ресурсам в приложении. Вот так компонент будет отрисовываться с помощью React Router:
Навигация между страницами JSF Механизм навигации определяет связь между логическим признаком Реализуется экземплярами класса NavigationHandler. Навигация нужна для переходов между представлениями. ● Правила задаются в файле faces-config. xml:
<navigation-rule> Правило навигации <from-view-id> Источник навигации, т. е. страница. <navigation-case> Один из вариантов правила навигации. <from-action> Выполнение определенного метода. <from-outcome> Условия по которому выбирается данный переход <to-view-id> Страница, на которую выполняется переход. <redirect/> Перенаправление с изменением URL страницы. ● Пример перенаправления на другую страницу:
Значение атрибута action, согласно принятому соглашению, является наименование страницы без указания расширения '.xhtml'. Model 1 ● Предназначена для проектирования приложений небольшого масштаба и сложности. ● За обработку данных и представления отвечает один и тот же компонент (сервлет или JSP)
Model 2 (MVC) ● Предназначена для проектирования достаточно сложных веб-приложений. ● За обработку и представление данных отвечают разные компоненты (сервлеты и JSP) Сервлет действует как контроллер и отвечает за обработку запроса и создание компонентов Java-beans, используемых JSP, а также в зависимости от действий пользователя принимает решение, какой JSP-странице перенаправить запрос.
https://www. /archive/index2008421108.htm |
Шаблоны проектирования, что такое, с чем едят. Разница с архитектурными шаблонами 2. Backbone. JS, backbone. Model, Backbone. View 3. Написать фрагмент кода, который по нажатию кнопки увеличивает её значение на 1 ... <h:commandButton actionListener="#{myBean. increment}" value="0"/> ... | 1) Шаблон проектирования или паттерн — повторимая архитектурная конструкция, представляющая собой решение проблемы проектирования в рамках некоторого часто возникающего контекста (© Wikipedia). ● Описывает подход к решению типовой задачи. ● Одну и ту же задачу часто можно решить с использованием разных шаблонов. ● Существует много литературы с описанием различных шаблонов проектирования Архитектурные шаблоны Более высокий уровень по сравнению с шаблонами проектирования. ● Описывают архитектуру всей системы или приложения. ● Обычно имеют дело не с отдельными классами, а с целыми компонентами или модулями. ● Компоненты и модули могут быть построены с использованием различных шаблонов проектирования. 2) Backbone. js — это легкий MV*-фреймворк, позволяющий структурировать код JavaScript-приложений. Но прежде, чем говорить о нем, давайте разберемся с паттерном, а вернее, семейством паттернов MV* (Model-View-Whatever), наиболее известным из которых является паттерн MVC (Model-View-Controller). Модель (Model) — модель содержит некое состояние приложения (JSON данные, называемые в Backbone атрибутами), а также события, позволяющие управлять изменением состояния. Модель может храниться как в памяти браузера, так и в базе данных на сервере. Упорядоченная группа моделей — это коллекция. В Backbone. js коллекция представляет собой обертку для работы с группами моделей.
Представление (View) — представление содержит логику отображения данных модели и коллекций в пользовательском интерфейсе. Представление позволяет отделить данные от их конкретного отображения в DOM-модели, что позволяет отображать одни и те же данные в разных представлениях, а также реагировать всем представлениям на изменение состояния модели.
Атрибут $el ссылается на обертку, которую создает представление. В нашем примере, мы создали элемент <div> с классом ‘book-item’ и поместили в него заголовок книги. Также представления в Backbone. js могут слушать события от элементов DOM и от моделей и коллекций.
В данном примере мы в качестве обработчика щелчка мыши по элементу с классом title назначили функцию ’onTitleClick’ и определили эту функцию. Так представления могут реагировать на события пользовательского интерфейса и менять, соответственно, состояние модели и наоборот, отслеживать состояние модели и изменять отображение. Контроллер (Controller) — промежуточный слой между данными и представлением, контроллер передает данные в представление. Итак, Backbone. js состоит из следующих классов: Model (Модель) Collection (Коллекция) View (Представление) Router (Роутер) http://getinstance. info/articles/backbone-js/introduction-to-backbonejs/ 3) Написать фрагмент кода, который по нажатию кнопки увеличивает её значение на 1 JSF <h:form id="myForm"> <h:commandButton name="btn" actionListener="#{myBean. increment}" value="0"/> </h:form> Bean @ManagedBean(name="myBean") @SessionScoped public class myBean { public String increment(){ String value = FacesContext. getCurrentInstance(). getExternalContext().getRequestParameterMap().get("btn"); int i=Integer. ParseInt(value); i++; //методом аналогичным get на 16 строчке установить новое значение. //что-то типо этого FacesContext. getCurrentInstance(). getExternalContext().getRequestParameterMap().get("btn").value=i; } } |
Отличие ES5 от ES6 | 1. Блочная область видимости В ES5, если у вас есть функция внутри цикла (например, for(var i = 0; i < 3; i++) {...}) и эта функция пытается получить значение переменной i, вы получаете проблемы, связанные со всплытием. В ES6, если использовать let, такой проблемы нет. 2. Лексическое значение this(с помощью стрелочных функций) Лексическое this — это особенность, которая заставляет this всегда указывать на тот объект, в рамках которого физически находится функция. 3. Работа с arguments В ES5 arguments ведет себя как массив (мы можем пройтись по нему циклом), но это не массив. Т. е. методы массивов, такие как sort, slice и т. д., не доступны. 4. Классы Концептуально, в JavaScript нет такого понятия как класс, в отличие от объектно-ориентированных языков программирования, таких как Java. Но разработчики долгое время использовали функции, которые создавали объекты при вызове с ключевым словом new. 5. Строгий режим Строгий режим («use strict») помогает обнаружить наиболее общие проблемы JavaScript и повысить «безопасность». В ES5 строгий режим не обязателен, но в ES6 он необходим для большинства особенностей. Поэтому большинство людей используют строгий режим по умолчанию, а многие инструменты, такие как Babel, автоматически добавляют «use strict» в начало файла, позволяя нам писать лучший JavaScript. |
SPA структура jsf приложений | SPA http://www. codenet. ru/webmast/js/spa/ Структура JSF-приложения ● JSP или XHTML-страницы, содержащие компоненты GUI. ● Библиотеки тегов. ● Управляемые бины. ● Дополнительные объекты (компоненты, конвертеры и валидаторы). ● Дополнительные теги. ● Конфигурация — faces-config. xml (опционально). ● Дескриптор развёртывания — web. xml. |
1) jsf 2) jsx, как используется в react 3) ejb, реализующий калькулятор с 4 операциями | 1) JavaServer Faces (JSF) — это фреймворк для веб-приложений, написанный на Java. Он служит для того, чтобы облегчать разработку пользовательских интерфейсов для Java EE приложений. В отличие от прочих MVC фреймворков, которые управляются запросами, подход JSF основывается на использовании компонентов. Состояние компонентов пользовательского интерфейса сохраняется, когда пользователь запрашивает новую страницу и затем восстанавливается, если запрос повторяется. Для отображения данных обычно используется JSP. Динамические данные на JSF страницах моделируются с помощью специальных POJO, называемых управляемыми компонентами (JSF Backing Beans). Жизненным циклом подобных компонентов управляет контейнер. Имя управляемого bean-компонента также можно указать явно с помощью атрибута name аннотации ManagedBean, например: @ManagedBean(name = "home"). Для управляемых bean-компонентов возможно использование атрибута eager, если атрибут eager имеет значение true, то JSF создает этот управляемый bean-компонент при старте и помещает его в область видимости приложения. Также с помощью аннотации @ManagedProperty можно задать свойства управляемого bean-компонента. Технология JavaServer Faces включает:
Преимущества JSF
Структура JSF-приложения
2) JSX представляет комбинацию кода JavaScript и XML. ReactDOM. render( JSX не поддерживается браузерами. Поэтому предварительно надо весь код JSX скомпилировать в JavaScript. Для компиляции JSX в JavaScript используется специальный инструмент - Babel. babel подтягивает код JSX через AJAX. Поэтому просто кинуть веб-страницу в браузер у нас не получится, нам надо использовать для обращения к ней веб-сервер. https:///web/react/1.2.php https:///web/react/1.3.php 3) EJB, реализующий калькулятор с 4 операциями https:///m53pprcz (P. S. на всякий случай с интерфейсом, хотя можно и без него) @Remote public interface CalculatorInterface{ public double add(double a, double b); public double min(double a, double b); public double mult(double a, double b); public double div(double a, double b); } @Stateless(name="calculator") public class Calculator implements CalculatorInterface { public double add(double a, double b){ return a+b; } public double min(double a, double b){ return a-b; } public double mult(double a, double b){ return a*b; } public double div(double a, double b){ return a/b; } } |
1. Работа ajax в jsf 2. GWT, Vaadin 3. Написать компонент реакт для рендера таблицы | 1)Технология Ajax обычно требует выполнения двух шагов, которые, как правило, не выполняются для не-Ajax HTTP-запросов: частичная обработка форм на сервере и последующее частичное отображение объектной модели документа (DOM, Document Object Model) на клиенте. Частичная обработка и отображениеJSF 2 поддерживает частичную обработку и отображение за счет разбиения жизненного цикла JSF на две части: выполнение и отображение. На рисунке 5 показана часть, относящаяся к выполнению: Рисунок 5. Фаза выполнения жизненного цикла JSF
На рисунке 6 показана фаза отображения жизненного цикла JSF: Рисунок 6. Фаза отображения жизненного цикла JSF
Идея, лежащая в основе разделения жизненного цикла на фазы выполнения и отображения, довольно проста: можно указывать компоненты, которые JSF будет выполнять на сервере, а также компоненты, которые JSF будет перерисовывать при возвращении Ajax-ответа. Это делается с помощью появившегося в JSF 2 тега <f:ajax>, как показано в листинге 7: Листинг 7. Меню масштаба с использованием Ajax<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" Листинг 7 представляет собой модификацию меню, показанного в первой строке листинга 2: я удалил из листинга 2 атрибут onchange и добавил тег <f:ajax>. В этом теге <f:ajax> указывается:
Когда пользователь выбирает значение в меню масштаба, JSF делает Ajax-запрос на сервер. Далее JSF пропускает меню через фазу выполнения жизненного цикла (@this обозначает компонент, заключающий в себе тег <f:ajax>), и обновляет у меню свойство zoomIndex на этапе обновления данных модели. При получении Ajax-ответа JSF перерисовывает компонент map, в котором используется (вновь заданный) коэффициент масштабирования. Таким образом, добавив одну строку XHTML-кода, мы получили меню масштаба, использующее Ajax. Однако все можно сделать еще проще, так как JSF предоставляет значения по умолчанию для атрибутов event и execute. У каждого компонента JSF есть событие по умолчанию, при наступлении которого посылается Ajax-запрос, если внутри тега компонента имеется тег <f:ajax>. Для меню – это событие change. Это означает, что можно избавиться от атрибута event тега <f:ajax>, показанного в листинге 7. Значением по умолчанию для атрибута execute тега <f:ajax> является @this, обозначающее компонент, внутри которого находится тег <f:ajax. В нашем примере этим компонентом является меню, поэтому атрибут execute можно также опустить. Используя для атрибутов тега <f:ajax> значения по умолчанию, можно сократить листинг 7 до кода, показанного в листинге 8: Листинг 8. Упрощенная версия меню масштаба использующего Ajax<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" Вот так легко JSF 2 позволяет добавлять в компоненты технологию Ajax.
2) https://ru. wikipedia. org/wiki/Google_Web_Toolkit Vaadin https: //habrahabr. ru/post/115999/ 3) Написать компонент React для рендера таблицы var numbers=[{name:"a", price:"100"}, {name:"b", price:"200"}]; var Table=React. createClass({ var data=this. props. mas; render:function(){ var tableBody=this. generateTable(); return ( <table> {tableBody} <\table> ); }, generateTable:function(){ return data. map(function(el){ return (<tr> <td>{el. name}<td> <td>{el. price}<td> <tr>); }); } }); React. render(<Table mas={numbers}/>,document. getElemetnById('example')); |
1. MVC 2. Управление состоянием в React. Flux & Redux. 3. Фрагмент JSF, который будет выводить значение метода public String getName() из некоторого @ManagedBean (пакет и класс указаны) | 1) Model-view-controller (MVC, «Модель-представление-поведение», «Модель-представление-контроллер») —архитектура программного обеспечения, в которой модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на остальные. MVC состоит из трех компонент: View (представление, пользовательский интерфейс), Model (модель, ваша бизнес логика) и Controller (контроллер, содержит логику на изменение модели при определенных действиях пользователя, реализует Use Case). Основная идея этого паттерна в том, что и контроллер и представление зависят от модели, но модель никак не зависит от этих двух компонент. Это как раз и позволяет разрабатывать и тестировать модель, ничего не зная о представлении и контроллерах. В идеале контроллер так же ничего не должен знать о представлении (хотя на практике это не всегда так), и в идеале для одного представления можно переключать контроллеры, а так же один и тот же контроллер можно использовать для разных представлений (так, например, контроллер может зависеть от пользователя, который вошел в систему). Пользователь видит представление, на нем же производит какие-то действия, эти действия представление перенаправляет контроллеру и подписывается на изменение данных модели, контроллер в свою очередь производит определенные действия над моделью данных, представление получает последнее состояние модели и отображает ее пользователю. 2) https:///web/react/5.1.php https:///web/react/5.3.php 3) <h:outputText value=”#{пакет. класс. name}” /> |
1)Валидаторы JSF. Написание, назначения, способы создания 2)Способы конфигурирования Spring 3)Написать интерфейс на React с роутингом. Отображает 2 страницы "Новости" /news и "Главная" /home Переход должен осуществляться по ссылке | 1. Валидаторы в JSF 2. В настоящий момент Spring framework поддерживает четыре разных способа конфигурирования контекста.
https://easyjava. ru/spring/spring-framework/inicializaciya-spring-java-konfiguraciya-annotacii-xml-i-groovy/ https://habrahabr. ru/post/222579/ 3.https:///avstv0rz <!DOCTYPE html> <html> <head></head> <body> <div id="menu"></div> <div id="content"></div> <script type="text/babel"> const Router = ReactRouterDOM. BrowserRouter; const Route = ReactRouterDOM. Route; const Switch = ReactRouterDOM. Switch; class Menu extends ponent { render() { return ( <ul> <li><Link to='/home'>Home</Link></li> <li><Link to='/news'>Roster</Link></li> </ul>); } } class Content extends ponent { render() { return ( <Router> <Switch> <Route path="/home" component={Home} /> <Route path="/news" component={News} /> </Switch> </Router> ); } } class Home extends ponent { render() { return <h1>Home page</h1>; } } class News extends ponent { render() { return <h1>News page</h1>; } } ReactDOM. render( <Menu/>, document. getElementById("menu") ) ReactDOM. render( <Content/>, document. getElementById("content") ) </script> </body> </html> |
Создание пользовательского интерфейса JSF, иерархия компонентов. React JS, ключевые особенности, архитектура приложения. Запрос на JPQL, получить всех совершеннолетних сотрудников, хранится ДР датой (погуглите конвертацию в годы и получение текущей) |
3.JPQL (Java Persistence query language) это язык запросов, практически такой же как SQL, однако вместо имен и колонок таблиц базы данных, он использует имена классов Entity и их атрибуты. В качестве параметров запросов так же используются типы данных атрибутов Entity, а не полей баз данных. SELECT p FROM Person p WHERE ((YEAR(CURRENT_DATE)-YEAR(p. birthDate))>18) |
1)конвертеры в jsf 2)двухфазовый и трехфазовый (?) конструктор в спринге и j2ee 3) интерфейс на gwt(!), который дергает jsessionid, и если его нет, то надо залогинить пользователя |
Порядок выполнения: constructor @postConstruct afterPropertiesSet initMethod
3)https:///KmmuvCrw //На сервере получаем Id сессии и должны отправить его в ответе String jSessionId=this. getThreadLocalRequest().getSession().getId(); //Все RPC методы будут также передавать копию JSESSIONID cookie в параметрах. //Сервлет будет сравнивать переданную копию с header cookie, и если они совпали, то пользователь залогинен, //иначе, нужно перенаправить на страницу с регистрацией. //ЭТО В ТЕОРИИ, А КАК РЕАЛЬНО СДЕЛАТЬ НЕ ЗНАЮ public void Login(){ //На клиенте получаем Id String jSessionId=Cookies. getCookie("JSESSIONID"); if(jSessionId==null){ //залогинить пользователя... //redirect("login_page") } } |
location transparency | location transparency - Реальное местонахождение файла не важно. Использование имен(например) для идентификации ресурсов вместо их фактического расположения. Например, доступ к файлу предоставляется по уникальному имени, хотя сам файл расположен где-то на жестком диске. |
проблемы реляционного отображения | ORM Ї Object/Relational Mapping Ї преобразование данных из объектной формы в реляционную и наоборот. Сложности, возникающие при попытке отобразить один вид представления данных на другой, называют объектно - реляционным несоответствием Основные проявления объектно-реляционного несоответствия: 1)Проблема идентичности. 2)Представление наследования и полиморфизма. 3)Проблема навигации между данными.
В JPA описаны три стратегии наследования мапинга (Inheritance Mapping Strategies), то есть как JPA будет работать с классами-наследниками Entity: 1) одна таблица на всю иерархию наследования (a single table per class hierarchy) — все enity, со всеми наследниками записываются в одну таблицу, для идентификации типа entity определяется специальная колонка “discriminator column”. Например, если есть entity Animals c классами-потомками Cats и Dogs, при такой стратегии все entity записываются в таблицу Animals, но при это имеют дополнительную колонку animalType в которую соответственно пишется значение «cat» или «dog». Минусом является то что в общей таблице, будут созданы все поля уникальные для каждого из классов-потомков, которые будет пусты для всех других классов-потомков. Например, в таблице animals окажется и скорость лазанья по дереву от cats и может ли пес приносить тапки от dogs, которые будут всегда иметь null для dog и cat соотвественно. 2) объединяющая стратегия (joined subclass strategy) — в этой стратегии каждый класс enity сохраняет данные в свою таблицу, но только уникальные колонки (не унаследованные от классов-предков) и первичный ключ, а все унаследованные колонки записываются в таблицы класса-предка, дополнительно устанавливается связь (relationships) между этими таблицами, например в случае классов Animals (см. выше), будут три таблицы animals, cats, dogs, причем в cats будет записана только ключ и скорость лазанья, в dogs — ключ и умеет ли пес приносить палку, а в animals все остальные данные cats и dogs c ссылкой на соответствующие таблицы. Минусом тут являются потери производительности от объединения таблиц (join) для любых операций. 3) одна таблица для каждого класса (table per concrete class strategy) — тут все просто каждый отдельный класс-наследник имеет свою таблицу, т. е. для cats и dogs (см. выше) все данные будут записываться просто в таблицы cats и dogs как если бы они вообще не имели общего суперкласса. Минусом является плохая поддержка полиморфизма (polymorphic relationships) и то что для выборки всех классов иерархии потребуются большое количество отдельных sql запросов или использование UNION запроса. |
Принципы IoC и CDI | IoC - это некий абстрактный принцип, набор рекомендаций для написания слабо связанного кода. Суть которого в том, что каждый компонент системы должен быть как можно более изолированным от других, не полагаясь в своей работе на детали конкретной реализации других компонентов.
— позволяет снизить (или совсем убрать ) |
JNDI | Это набор Java API, организованный в виде службы .lookup("Database"); имя объекта, к которому хочешь получить доступ |
Jndi. Методы. Способы Проблемы реляционного отображения и способы решения Конфигурация бина через аннотации( имя sample, контекст как у бина anothersample) | http://java-online. ru/jndi. xhtml 1) Основные проявления объектно-реляционного несоответствия: 1)Проблема идентичности. 2)Представление наследования и полиморфизма. 3)Проблема навигации между данными. Смотри презентаху
|
Ioc cdi веб-сервисы Soa многострочное текстовое поле, где только нижние буквы Jsf | Семрвис-ориентимрованная архитектумра (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам. Программные комплексы, разработанные в соответствии с сервис-ориентированной архитектурой, обычно реализуются как набор веб-служб, взаимодействующих по протоколу SOAP, но существуют и другие реализации (например, на базе jini, CORBA, на основе REST). Главное, что отличает SOA — это использование независимых сервисов с чётко определёнными интерфейсами, которые для выполнения своих задач могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу. SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путём комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определённого платформенно-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса. http://info. javarush. ru/eGarmin/2015/03/14/%D0%92%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81%D1%8B-%D0%A8%D0%B0%D0%B3-1-%D0%A7%D1%82%D0%BE-%D1%82%D0%B0%D0%BA%D0%BE%D0%B5-%D0%B2%D0%B5%D0%B1-%D1%81%D0%B5%D1%80%D0%B2%D0%B8%D1%81-%D0%B8-%D0%BA%D0%B0%D0%BA-%D1%81-%D0%BD%D0%B8%D0%BC-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0%D1%82%D1%8C-.html 3)
|
1) Профили платформы Java EE 2) Способы доступа к реляционным БД из Java-приложений, их преимущества и недостатки 3) JSF Manager Bean, после инициализации HTTP-сессии формирующий коллекцию с содержимым таблицы Н_УЧЕБНЫЕ_ПЛАНЫ. Для достпула к БД необходимо использовать JDBC-ресурс jdbc/OrbisPool. | 1) ●Появились в Java EE 6. ● Позволяют сделать более «лёгкими» приложения, которым не нужен полный стек технологий Java EE. ● Существует только 2 профиля — Full и Web. ● Сервер приложений может реализовывать спецификации не всей платформы, а конкретного профиля. 2) ● JDBC; ● ORM-фреймворки (Hibernate, TopLink, …); ● Java Persistense API (JPA 2.0). 3) |
rmi наследование и полиморфизм в orm бин возвращающий время работы сервера | @ManagedBean class Bean{ private int t=0; public int getT(){ FacesContext. getWorkingTime(); } } |
JPA
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 |
