Требуется помощь по разработке Java EE

Question

Я использую шаблон MVC в своем веб-приложении. В которой у меня три слоя

1. Управления слои
2. Менеджер слои
3. ДАО слой

И я использую DTOs от контрольного слоя до сены, а затем к слою Dao и так же, как противоположность.

Вопрос в том, что основная цель DTO? Могу ли я использовать DTO для сопоставления нашей таблицы реляционных баз данных, или мне нужно использовать «Bean»?

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

Answer 1

Нет проблем с использованием DTO и сопоставления их с таблицами базы данных. Но вам придется делать сопоставление самостоятельно (используя JDBC, Spring JDBC и т. Д.).

Другим вариантом является использование ORM для преобразования ваших DTO в базу данных. Вы даже можете создавать свойства, не привязанные к вашим таблицам. Взгляните на JPA.

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

Answer 2

Мой вопрос в том, что является основной задачей DTO?

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

Именно поэтому они называют это объектом передачи данных.

Могу ли я использовать DTO, чтобы сопоставить нашу реляционную таблицу базы данных или я должен пойти с «Bean»?

Независимо от того, принимаете ли вы использование форматированных аксессуаров JavaBean или ваших собственных аксессуаров, на самом деле это не имеет значения с DTO. Обе стороны передачи должны быть в согласии; но если у вас есть сеттер setName(...) или сеттер name(...), это не повлияет на функциональность.

Хотя это не имеет значения в смысле функциональности, лучше придерживаться установленных соглашений об именах, чтобы упростить пересмотр кода и отсутствие путаницы при обучении новых сопровождающих. Кроме того, несколько библиотек могут предполагать, что вы используете соглашения с bean (или требуете их). Если вы не уверены, лучше придерживаться стандартных соглашений JavaBean, так как ваши новые соглашения, вероятно, не тестируются (или как формальные).

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

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

Answer 3

Основная цель DTO - уменьшить накладные расходы при передаче данных по слоям.

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

Определенно, у вас есть возможность сопоставить ваши DTO с вашими таблицами базы данных и иметь конструкцию компонента, которая более тесно представляет объекты домена. Это один из способов сделать это.

И наоборот, в зависимости от вашей базы данных, ваш DTO могла бы быть больше в соответствии с вашими реальными хозяйствующими субъектами - только без логики

Answer 4

Мой вопрос состоит в том, что то, что является основной целью DTO?

Как расширения (Data Transfer Object) подразумевает, DTOS предназначены для передачи структурированных данных в различных уровнях. DTO позволяют отделять конкретные реализации протокола, которые представляют данные, так что данные из разных источников могут быть абстрагированы до общения на разных уровнях.

Например, DTOs позволят вам отделить данные, присутствующие в объекте HttpServletRequest, от его внутренней памяти, чтобы вы могли отправлять данные службе на уровне бизнес-логики. То же самое относится к DTO, используемым для абстрагирования результатов, полученных из SQL-запроса и находящихся в объекте ResultSet. Короче говоря, DTO позволяют передавать данные, не помещая их в исходный код - вы можете забыть об ответах HTTP и соединениях JDBC во время работы с данными.

Могу ли я использовать DTO, чтобы сопоставить нашу реляционную таблицу базы данных или я должен пойти с «Bean»?

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

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

Это зависит от того, как вы хотите соединить DTO с таблицей базы данных. Предпочтительно иметь взаимно однозначное сопоставление между DTO и таблицей базы данных и выбирать другой DTO для передачи свойств, не связанных с таблицей. В конце концов, DTO, как и любой другой объект, должны нести единую ответственность. Если ответственность заключается в отражении таблицы базы данных, тогда она должна содержать другие «нерелевантные» свойства.

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