DTO, DAO and MVC Concept
Que 1 : Why do we use DTO and DAO , and when should we use them ? If you are developing a GUI Java software to do with inserting, editing, deleting data. But you are struggling to distinguish between DTO/DAO and Model , View , Controller (MVC) Structure? Are they similar, which is better to use when interacting with database through Java GUI .
Answer : DTO is an abbreviation for Data Transfer Object, so it is used to transfer the data between classes and modules of your application.
- DTO should only contain private fields for your data, getters, setters, and constructors.
- DTO is not recommended to add business logic methods to such classes, but it is OK to add some util methods.
DAO is an abbreviation for Data Access Object, so it should encapsulate the logic for retrieving, saving and updating data in your data storage (a database, a file-system, whatever).
Here is an example of how the DAO and DTO interfaces would look like:
The MVC is a wider pattern. The DTO/DAO would be your model in the MVC pattern.
It tells you how to organize the whole application, not just the part responsible for data retrieval.
Que 2 : Whether it is a good practice to have view and Controller in one class. If we think about Netbeans , you can create GUI Frame Class and add components like JButton onto the frame, double clicking the button will take you to the actionListener method(Controller) which appears to be in the frame the data is to be displayed to the user (View). So they're in the same class. Is that completely going against the concept then or not?
Answer : If you have a small application it is completely OK, however, if you want to follow the MVC pattern it would be better to have a separate controller, which would contain the business logic for your frame in a separate class and dispatch messages to this controller from the event handlers.
This would separate your business logic from the view.
DTO слой имплементация
Имеется модель объектов, DAO интерфейсы для каждого класса объектов, сервис классы с имплементацией каждого DAO интерфейса. Требуется реализовать слой DTO. Подскажите чем отличается DTO от реализации DAO? И как правильно организовать в таком случае DTO?
DTO — это аббревиатура для передачи данных объекта, поэтому он используется для передачи данных между классами и модулями вашего приложения. DTO должен содержать только private поля для ваших данных, getters, setters и конструкторы. Не рекомендуется добавлять бизнес-логики методы таких классов, но это нормально, чтобы добавить некоторые утилиты.
DAO — это аббревиатура для объекта доступа к данным, поэтому он должен инкапсулировать логику для извлечения, сохранения и обновления данных в хранилище данных (базы данных, файл-системы, что угодно). Ниже приведен пример того, как интерфейсы DAO и DTO бы выглядеть следующим образом:
DTO является объектом передачи данных. Это в основном объект значение, используемое для передачи структурированных данных между уровнями / слоями
DAO является объектом доступа к данным. Он несет ответственность за сокрытие деталей реализации о том, как хранятся ваши данные и как он извлекается.
What is the difference between DTO and DAO
DAO is a class that usually has the CRUD operations like save, update, delete. DTO is just an object that holds data. It is JavaBean with instance variables and setter and getters.
A DAO can be thought of as a proxy used by the business tier who is its client to retrieve values from any given resource such as a RDMS, LDAP server, XML repository, OODB, flat files and so forth. Here is how it looks:
your code -> DAO -> JDBC
The DTO, Value Object(VO) is used to expose several values in a bean like fashion. This provides a light-weight mechanism to transfer values over a network or between different application tiers.
DTO will be passed as value object to DAO layer and DAO layer will use this object to persist data using its CRUD operation methods.
The advantage of the DAO layer is that if you need to change the underlying persistence mechanism you only have to change the DAO layer, and not all the places in the domain logic where the DAO layer is used from. The DAO layer usually consists of a smaller set of classes, than the number of domain logic classes that uses it. Should you need to change what happens behind the scene in the DAO layer, the operation is somewhat smaller, since it only affects the DAO layer.
The advantage of DTO layer is that it adds a good deal of flexibility to the service layer and subsequently to the design of the entire application. For example, if DTOs are used, a change in the requirements that forces a move to a different amount of data doesn’t have any impact on the service layer or even the domain. You modify the DTO class involved by adding a new property, but leave the overall interface of the service layer intact.
Name already in use
Java-Interview-Questions / Terms / terms.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Описать простыми словами термины, встречающиеся при разработке web-приложений:
из браузера
- передаем HTTP-запрос , который попадает в
web (controller, view, ui) layer
- если — это REST-controller у которого есть внешнее API для сторонних приложений (внешних сервисов), то он принимает информацию снаружи через REST-запросы (по протоколу HTTP ). Переданный в слой запрос (с параметрами) обрабатывается, и результатом его работы являются какие-то сущности ( entities ). Далее, этот слой обращается к
service layer
- в котором находится и выполняется над сущностями некая бизнес-логика. Если по ходу выполнения бизнес-логики Сервисному слою нужны данные из базы данных (или иного места хранения), то для этого он задействует
dao (repository) layer
- который в свою очередь обращается в базу (или другие источники хранения данных). Данный слой работает с сущностями предметной области, т.е. сохраняет или достает из источника хранения данных entities , которые преобразуются в DTO (т.е. объекты, которые приближены по своей структуре к объектам бизнес-логики) и передаются вверх по цепочку слоев, попадая в итоге наружу (клиенту, отправившему запрос)
domain (model, entity) layer
- слой, описывающий сущности предметной области без какой-либо логики (только данные), т.е. классы, структура которых максимально приближена к формату таблиц, хранящихся в базе данных (или иного источника)
Plain Old Java Object, старый добрый Java-объект — это объект, состоящий чаще всего из набора полей, их геттеров/сеттеров и без дополнительной нагрузки в виде:
Extend prespecified classes, as in
Implement prespecified interfaces, as in
Contain prespecified annotations, as in (хотя статья на сайте Спринга допускает наличие аннотаций для POJO-объектов )
Термин POJO возник в качестве ответной реакции на появление платформы J2EE и ее широко распространившееся внедрение в приложениях, из-за чего, в частности, усложнился весь процесс их разработки. Мартин Фаулер с коллегами придумали данный термин для описания класса, свободного от «немого» кода, который требовался лишь для корректной работы среды выполнения
POJO был представлен в качестве альтернативы для Enterprise JavaBeans (EJB) и других «тяжелых» enterprise-конструкций, которые были популярны в 2000-х годах (об этом можно почитать в статье Сергея Немчинского)
POJO — это класс, который не использует специальные возможности различных фреймворков (т.е. он не прибит гвоздями к архитектуре какой-либо библиотеки, а также не привязан к фреймворку, который его использует [вспомним Spring и поулыбаемся]), таких, как Spring , EJB и пр. Данные фреймворки появились позже и поэтому в названии присутствует слово «старый»
Пример:
Основной целью POJO было показать, что сущности могут быть успешно смоделированы без использования JavaBeans . Более того, JavaBeans вообще не должны быть использованы для этой цели
Таким образом, основной посыл POJO — упрощение классов-сущностей насколько, насколько это возможно для моделирования предметной области
Резюмируя все вышесказанное, можно сказать, что POJO — этот класс, который ничего не делает и имеет только состояние
не путать с Enterprise JavaBeans
это класс в языке Java, написанный по определённым правилам:
- должен быть сериализуемыми (реализовывать интерфейс java.io.Serializable )
- должен иметь конструктор без аргументов
- все поля JavaBean должны быть закрытыми (private)
- доступа к полям осуществляется через методы доступа getters (аксессоры) и setters (мутаторы)
- методы equals() , hashCode() и toString() должны быть переопределены
Пример:
«Сущности» — это классы, моделирующие объекты предметной области
По своей структуре они приближены к таблицам базы данных (типы и названия столбцов таблицы == типам и названиям полей в классе, взаимодействующему с конкретной таблицей)
Хранятся в domain слое
Сущности обладают неотъемлемой идентичностью, основанной на эквивалентности их id . Это значит, что если данные в двух сущностях полностью одинаковы (за исключением id поля), они не являются одной и той же сущностью
Сущности почти всегда изменяемы (мутабельны)
«Объект-значение» ⎼ термин из среды DDD ⎼ это объект без специальных методов, имеющий набор свойств (полей) примитивных типов данных или тоже Value object
Объекты данного рода проверяются на равенство исходя не из физической одинаковости (одинаковости ссылок на них), а из значений свойств
Примером VO является любой класс, который реализует равенство через равенство содержащихся в нем данных
В отличие от Entity не обладает идентичностью. На практике это означает, что объекты-значения не имеют поля-идентификатора: если два экземпляра одного объекта-значения обладают одинаковым набором атрибутов, то они равны
Объекты-значения должны быть неизменяемы (immutable). Это значит, что если требуется изменить такой объект, то для этого придется создать его новый экземпляр, вместо того чтобы изменять существующий
Объект-значение всегда должен принадлежать одной или нескольким сущностям, он не может жить собственной жизнью
Чтобы распознать объект-значение, мысленно замените его на Integer
Объекты-значения не должны иметь собственной таблицы в базе данных
Пример: Integer , Money , Даты
Data Transfer Object, объект переноса данных ⎼ это паттерн, который предполагает использование отдельных классов для передачи данных (объектов без поведения) между слоями, c целью уменьшения количества запросов к базе данных
Данный класс, если его необходимо передавать по сети, должен быть сериализуемым (в XML , JSON и тд)
Это объект, который собирается из низкоуровневых данных ( entities ), а затем используется на слое service и controller . Те, при обращении к Repository из service , последний получает entity (набор табличных записей, которые возвращаются в результате выполнения SQL-запроса ), преобразует его в DTO и отдает на слой web .
DTO можно рассматривать как хранилище информации, единственная цель которого — передать данные получателю
Примером DTO является любой класс, который содержит только поля и методы по извлечению этих данных
DTO может собираться (состоять) из нескольких entity , взятых из базы данных
Data Access Object, объект доступа к данным — абстрактный интерфейс к какому-либо типу базы данных или иному механизму хранения
Описание проблемы
Способ доступа к данным бывает разным и зависит от источника данных. Способ доступа к базе данных зависит от типа хранилища (реляционные базы данных, объектно-ориентированные базы данных, однородные или «плоские» файлы и т.д.). Унифицированный API для доступа к этим несовместимым системам отсутствует. А использование конкретного способа доступа создает зависимость между кодом приложения и кодом доступа к данным
Такая зависимость кода может сделать миграцию приложения от одного типа источника данных к другому трудной и громоздкой
Для доступа к данным хотелось бы использовать какой-либо универсальный способ (паттерн), позволяющий скрыть процесс их получения
Для решения вышеперечисленной проблемы обычно используют паттерн DAO
Описание паттерна
Данный паттерн абстрагирует и инкапсулирует доступ к источнику данных, а также управляет соединением с ним для получения и записи данных
В самом широком смысле, DAO — это класс, содержащий CRUD-методы для конкретной сущности
DAO полностью скрывает от клиента детали реализации взаимодействия с хранилищем данных. Поскольку при изменениях источника данных представляемый DAO интерфейс не изменяется, этот паттерн дает возможность DAO принимать различные схемы хранилищ без влияния на клиента или бизнес-компоненты. По существу, DAO выполняет функцию адаптера между компонентом и источником данных
Шаблон DAO используется для связи программы, написанной на Java с реляционными базами данных через интерфейс JDBC
JDBC API позволяет в приложениях использовать SQL-команды, являющиеся стандартным средством доступа к таблицам
Также DAO — это промежуточный слой, который скрывает от клиента реализацию взаимодействия с разными хранилищами данных, способы и механизмы хранения, предлагая при этом единые требования по функционалу в виде интерфейса
Паттерн DAO позволяет:
- отделить интерфейс(логика) от реализации: в начале определяем интерфейсы, а потом под них делаем любую реализацию в любом количестве, которую можно переключать в любое время — клиент ничего не заметит
- клиенту не зависеть от конкретного источника данных — ему все равно кто передает эти данные, он лишь дергает методы
- внедрять большое количество реализаций интерфейсов
Проблемы DAO
Большая часть людей представляет DAO некими вратами к базам данных, беспрепятственно добавляя в него множество методов для доступа к базе. Поэтому нередко можно увидеть слишком раздутое DAO c большим количеством методов на все случаи жизни
Чтобы уйти от этого, предлагается использовать паттерн Repository
«Хранилище» ⎼ паттерн, выполняющий роль коллекции объектов из domain layer в оперативной памяти
Хранилище позволяет добавлять или удалять объекты, как будто мы работаем с обычными коллекциями
Тот факт, что объект из domain layer на самом деле не находятся в хранилище, полностью скрыт от клиентских программ. Для них ⎼ это выглядит, как коллекция в памяти
Данный слой используется в Spring Data JPA
- DAO ⎼ это низкоуровневый слой, который работает с объектами базы
- Repository ⎼ работает с объектами DTO
- Если Entity не переводятся в DTO , то два этих слоя сливаются, выполняя в итоге одну и туже функцию, т.е. Repository становится DAO
REpresentational State Transfer, передача состояния представления
REST определяет набор операций, которые, например User может выполнять над Meals
REST-Controller — способ общения с внешними приложениями через установленный набор методов, за которые они могли бы дёргать наше приложение