Чем dao отличается от dto
Перейти к содержимому

Чем dao отличается от dto

  • автор:

Чем dao отличается от dto

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

Спросил safonovea
1011 дн., 22 час., 2 мин. назад

Лучший ответ:

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

DAO

Итак, паттерн DAO (Data Access Object) получил особо широкое распространение и применение в мире J2EE. Его прямое предназначение — абстрагировать и инкапсулировать доступ к источнику данных. DAO управляет соединением с источником данных для получения и записи данных.

В классическом варианте DAO содержит только стандартные CRUD-методы. Клиент вызывает эти методы получая или передавая в качестве аргумента так называемый DTO (Data Transfer Object).

По сути, DAO является реализацией слоя отображения реляционных данных в объекты и наоборот. Именно здесь сосредотачивается решение проблемы, известной как «Object-relational impedance mismatch».

Repository

Рассмотрим теперь паттерн Repository. Repository выступает в роли посредника между слоем домена и слоем отображения реляционных данных. Он выполняет роль коллекции объектов домена в оперативной памяти. Таким образом, репозиторий представляет собой более высокий уровень абстракции над слоем отображения данных.

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

Объекты, запрашиваемые у репозитория, могут иметь довольно сложную структуру. Например, объект Employee может содержать ссылку на объект Organization. Для того, чтобы обеспечить корректную работу по сохранению и загрузке подобных объектов репозиторию может понадобиться один или несколько DAO.

Выводы

Что же мы имеем в итоге? Выходит, что вопрос о взаимоисключающем использовании паттернов Repository и DAO несколько некорректен. Эти решения можно задействовать в связке. Применяя Repository как коллекцию объектов в памяти, мы можем поместить DAO на более низкий уровень и инкапсулировать в нем логику обращения к источнику данных. Важно помнить об обязанностях каждого из решений.

Ниже приведу краткий список тезисов, характеризующих различия между Repository и DAO:

  • DAO инкапсулирует доступ к источнику данных
  • DAO является реализацией слоя объектно-реляционного отображения
  • DAO более ориентирован на источник данных
  • Repository представляет более высокий уровень абстракции
  • Repository выполняет роль коллекции объектов домена в памяти
  • Repository ориентирован на модель предметной области

Ответил safonovea
1008 дн., 22 час., 3 мин. назад

Правильно я понимаю, что если доступ к данным реализуется через ORM-библиотеку, то слой DAO отсутствует и создается только слой репозиториев, которые используют API ORM для получения/сохранения данных?

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

Ну если используется зрелое ORM решение, типа (N)Hibernate, то о кешировании можно особенно не беспокоиться (во всяком случае на уровне репозитория).

Повторное использование знаний

В чем разница между DAL, DTO и DAO в стиле трехслойной архитектуры, в том числе с MVC?

В больших приложениях MVC является только слоем представления N-х уровней архитектуры.

Я действительно запутался, как это может быть даже возможно, например, в стиле 3-х уровней архитектуры, где MVC — это просто уровень представления, а DTO, DAO, DAL — это только часть уровня сохранности данных. Я полностью потерялся.

Я был бы рад, если бы кто-то сказал мне правду о том, как это работает вместе.

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

Я ценю любой ответ!

Поделиться Источник 05 июня 2016 в 17:47

2 ответа

Давайте начнем с цели каждого: —

DTO

Объекты передачи данных. Они обычно используются для передачи данных из контроллера в клиент (JS). Термин также используется для POCOs/POJOs немногими, которые фактически содержат данные, извлеченные из базы данных.

DAO

Объект доступа к данным является одним из шаблонов проектирования, используемых для реализации DAL. Он собирает и выполняет запросы в базе данных и отображает результат в POCO/POJO с помощью различных других шаблонов, включая ‘Объект запроса’, ‘Маппер данных’ и т.д. Слой DAO может быть расширен с помощью шаблона ‘Repository’.

DAL

Слой доступа к данным абстрагирует ваши действия в базе данных с помощью DAO/Repository/POCO и т.д. ORMs помогают вам собрать ваш DAL, но он может быть реализован без использования их.

MVC

Управление представлением модели — это шаблон, который используется для отделения представления (представления) от бизнес-логики. Для MVC не важно, реализован ли DAL или нет. Если DAL не реализован, логика базы данных просто переходит в вашу модель, что не является хорошим подходом.

В больших приложениях MVC является уровнем представления только N-уровневой архитектуры.

Модели используют большую часть вашей бизнес-логики, как указано выше. В N-уровневом приложении, если бизнес-логика полностью отделена для целей повторного использования в приложениях/платформах, то модели в MVC называются анемичными моделями. Если BI не нужно использовать в таком масштабе в вашем приложении, вы можете использовать Model, чтобы удержать это. Нет путаницы, верно?

Был бы рад, если бы кто-то рассказал мне правду о том, как это работает вместе.

Все паттерны MV* определяют только идею/концепцию; они не определяют реализацию. Паттерны MV* в основном фокусируются на отделении представления от BI. Просто сосредоточьтесь на этом.

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

Поделиться 10 июня 2016 в 14:56

Возможно, вам захочется сначала различить паттерн MVC и 3-х уровней архитектуры. Чтобы суммировать:

3-х уровней архитектуры:

  • данные: сохраняющиеся данные;
  • сервис: логическая часть приложения;
  • презентация: hmi, веб-сервис.

Теперь, для вышеуказанной 3-х уровней архитектуры, паттерн MVC происходит на уровне презентации (для веб-приложения):

  • данные. ;
  • сервис. ;
  • презентация:
    • контроллер: перехватывает HTTP-запрос и возвращает HTTP-ответ;
    • модель: хранит данные, которые должны отображаться/обрабатываться;
    • представление: организует вывод/отображение.

    Жизненный цикл типичного HTTP-запроса:

    1. Пользователь отправляет HTTP-запрос;
    2. Контроллер перехватывает его;
    3. Контроллер вызывает соответствующую службу;
    4. Служба вызывает соответствующий dao, который возвращает некоторые сохраняющиеся данные (например);
    5. Служба обрабатывает данные и возвращает данные в контроллер;
    6. Контроллер сохраняет данные в соответствующей модели и вызывает соответствующее представление;
    7. Представление создается с данными модели и возвращается в качестве HTTP-ответа.

    Использование DTO и DAO в Java GUI: практики MVC

    DTO (Data Transfer Object, объект передачи данных) предназначен для инкапсуляции и передачи данных между разнообразными компонентами системы, выполняя функцию сорта «почтальона». В то же время, DAO (Data Access Object, объект доступа к данным) обслуживает операции с базой данных, функционируя как «библиотекарь», предоставляющий данные. В архитектурном шаблоне MVC (Model-View-Controller, Модель-Представление-Контроллер) эти сущности воплощаются в контексте компонента Модель и взаимодействуют с Контроллером и Представлением, при этом соблюдая принципы инкапсуляции.

    Посмотрим на пример для Java:

    Скопировать код

    // DTO, функционирующий как "почтальон", переносит информацию о пользователе public class UserDTO < private String name; private String email; // Геттеры и сеттеры обеспечивают безопасный доступ к данным >// DAO действует как "библиотекарь", управляющий информацией о пользователе public interface UserDAO < // Метод для поиска пользователя и ничего более UserDTO fetchUser(int id); // Тут может быть и другая функциональность. >// Контроллер взаимодействует с DAO и DTO для отображения информации о пользователе public class UserController < private UserDAO userDao; // Отображает информацию о пользователе, не его внутренние данные public UserDTO displayUser(int userId) < return userDao.fetchUser(userId); >>

    UserDTO служит для транспортировки данных, UserDAO предоставляет доступ к хранению данных, а UserController организует процесс обмена данными, разделяя логику взаимодействия с базой данных и бизнес-логику представления.

    Изучая паттерны

    Осознанное использование взаимодействия между DTO, DAO и MVC заметно повышает производительность архитектуры приложения.

    Разделение обязанностей и эффективность

    DTO структурирует данные для передачи, снабженные геттерами/сеттерами для доступа. DTO не включает в себя бизнес-логики и не связан с информацией о базе данных.

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

    В шаблоне MVC DTO и DAO взаимодействуют так, что Контроллер может получать данные из DAO, упакованные в DTO, и передавать их Представлению, соответствуя принципам разделения обязанностей и изоляции компонентов.

    Оптимизация при масштабировании

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

    Создание благоприятной среды для тестирования

    Качественная реализация паттернов MVC, DTO и DAO открывает удобные возможности для модульного и интеграционного тестирования, повышая уровень контроля и облегчая отладку.

    Визуализация

    Аналогия с кухней в ресторане поможет лучше понять взаимодействие и роли:

    Взаимодействие базы данных с шаблонами проектирования DAO и DTO

    DAO означает объект доступа к данным и является шаблоном промышленного дизайна. В этой статье я расскажу, что такое DAO и как создать DAO. Я также расскажу о значении создания объектов доступа к данным.

    Существуют инструменты, которые могут генерировать код DAO для приложения. Но можно также написать классы DAO вручную. Еще один шаблон проектирования, тесно связанный с DAO, — это DTO (объект доступа к данным).

    Шаблон проектирования DAO помогает приложению выполнять различные операции CRUD над базой данных. Классы DAO предоставляют методы для вставки, удаления, обновления и методов поиска. Основной целью создания DAO является слабая связь и неповторение кода.

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

    Чтобы преодолеть вышеупомянутые проблемы, была изобретена схема проектирования DAO. Предполагается, что шаблон DAO имеет интерфейс, класс и фабрику DAO, соответствующие каждой таблице в таблице. Например, если в базе данных есть имя таблицы Employees, то должен существовать интерфейс с именем EmployeesDAO, класс с именем EmployeesDAOImpl и фабричный класс EmployeeDAOFactory.

    Интерфейс EmployeesDAO должен выглядеть примерно так:

    package com.company.app.dao;public interface < public Employee[] findAll() throws SQLException; public Employee findByPK(EmployeePK) throws SQL Exception; public Employee[] findbyemployeename(String EmployeeName) throws SQLException; public boolean insert(Employee employee) throws SQLException; public boolean update(Employee employee) throws SQLException; public boolean delete(Employee employee) throws SQLException;>

    Класс реализации DAO выглядит так:

    package com.company.aap.doaimpl;public class EmployeeDAOImpl implements EmployeeDAO < Connection con; ResultSet rs; PreparedStatement stmt; public Employee[] findAll() throws SQLException < Employee[] employees; String SQL_QUERY= “Select * from Employee”; con=ResourceManager.getConnection(); stmt = con.prepareStatement(SQL_QUERY); rs = stmt.executeQuery(); while(rs.next) < //get columns and store in array > return employees; > public Employee findByPK(EmployeePK) throws SQL Exception < //Implementation code >public Employee[] findbyemployeename(String EmployeeName) throws SQLException < //Implementation code >public boolean insert(Employee employee) throws SQLException < //Implementation code >public boolean update(Employee employee) throws SQLException < //Implementation code >public boolean delete(Employee employee) throws SQLException< //Implementation code >>

    В приведенном выше коде реализации DAO класс Employee является объектом передачи данных, который имеет переменные-члены, соответствующие таблице Employee в базе данных. Таким образом, Employee — это POJO в некотором смысле с геттерами и сеттерами для переменных-членов.

    Класс DAO Factory, который представляет собой EmployeeDAOFactory, используется для возврата объекта EmployeeDAOImpl. Вот код для DAO facrory для EmployeeDAO:

    package com.company.app.factory;public class EmployeeDAOFactory < public static EmployeeDAO create() < return (new EmployeeDAOImpl()); >>

    В EmployeeDAOImpl есть класс ResourceManager, цель которого — создать соединение с базой данных и вернуть его обратно. Таким образом, этот класс действует как вспомогательный класс для различных других классов реализации DAO.

    Как я уже упоминал в начале этой статьи, есть инструменты, которые могут генерировать для вас код класса DAO, DTO и Factory. Эти инструменты полезны, потому что они автоматизируют генерацию классов DAO. Важность этих инструментов даже становится большой на начальном этапе разработки приложений, потому что схема базы данных часто сохраняет изменения и, следовательно, вручную вносит изменения в таблицы базы данных и код DAO. Здесь я перечисляю инструменты, которые могут генерировать код DAO для приложений Java:

    1. FireStrom DAO от Codefutures
    2. DaoGen от TitanicLinux.net
    3. Dao4J
    4. БД Визуал Архитектор

    Эти инструменты выполняют импорт таблиц из базы данных, запрашивая сведения о соединении, а затем генерируют классы DAO / DTO на основе импортируемых таблиц. Еще один важный момент, который полезен при использовании этих инструментов, заключается в том, что они проверяют первичные и внешние ключи структуры таблицы. Кроме того, типы данных базы данных преобразуются в соответствующие типы данных в Java в классах DAO / DTO.

    После того, как код был сгенерирован этими инструментами, всегда можно изменить код для оптимизации кода DAO.

    Всегда помните, что DAO, DTO, Factory, Loose Coupling (принцип SOLID), шаблоны проектирования Factory все вместе. Можно также создать пул соединений при использовании шаблона проектирования DAO. Важным моментом является то, что код становится чистым и понятным при использовании шаблонов проектирования DAO, DTO.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *