При реализации шаблона DAO в Java, как должны быть реализованы и использованы TransferObjects?

Question

Я реализую шаблон DAO, как указано в Core J2EE Patterns. В моем проекте у меня есть 3 модуля: core layer, который использует DAO-API layer, который реализован моим Service ProviderDAO-MySQL layer.

У меня есть вопросы по поводу дизайна и использования TransferObject с:

1a) Является ли это нормальным иметь TransferObject сек очень избыточные по сравнению с эквивалентными «бизнес-слой» классов, или «бизнес-слой» классы :TransferObject s?

Например, если в моем core layer У меня есть класс:

public class Customer { 
    private int id; 
    private String lname; 
    ... 
    //various methods here, plus getters/setters 
} 

В DAO-API layer, у меня будет:

public class CustomerTO implements Serializable { 
    private int id; 
    private String lname; 
    .... 
    //getters/setters here 
} 

Я ненавижу эту избыточность между Customer и CustomerTO. Кроме того, в «примере 9.5« Объект переноса клиента »Core J2EE Patterns, кажется, только один класс Customer, что являетсяTransferObject.

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

=>1b) Но, может быть, мой DAO-API layer должен быть частью моей core layer и CustomerбытьTransferObject?

=>1c) Или есть что-то, чего я упускаю, чтобы избежать избыточности между классом основного бизнес-уровня и его объектом передачи?

2) ли законны в не использование TransferObject s в качестве параметров при вызове методов Daos? Например:

public interface CustomerDAO { 
    public Collection<CustomerTO> getCustomersByNameAndCity(String name, String city); 
} 

Или я должен всегда использовать что-то вроде:

public interface CustomerDAO { 
    public Collection<CustomerTO> getCustomersByNameAndCity(CustomerTO to); 
} 

Каковы недостатки при использовании первого метода?

Answer 1

1a) Нормально ли иметь TransferObject Да, это нормально в сценариях, где вы не пытаетесь ограничить информацию в DTO, которую нужно отправить. Объект передачи данных - это объект, который используется для инкапсуляции данных и отправьте его из одной подсистемы приложения в другую.

1b) Но, может быть, мой слой DAO-API должен быть частью моего основного слоя, а Customer - TransferObject? Нет, слой DAO должен скрывать/инкапсулировать базовые данные данных в базе данных.DAO используются другими подсистемами для получения данных из источника данных независимо от способа его сохранения/получения. Основная цель DAO - предоставить простые API для выполнения CRUD для данных.

1c) Или есть что-то, чего я упускаю, чтобы избежать избыточности между классом основного бизнес-уровня и его объектом передачи? Если ваши DTO не ограничивают какую-либо информацию, вы можете использовать один и тот же класс из бизнес-уровня. Но это может вызвать проблемы в будущих улучшениях, когда вам нужно ограничить информацию.

2) Является ли законным не использовать TransferObjects в качестве параметров при вызове методов DAOs? Например, Никто не может остановить вас. Но иногда атрибуты DTO и атрибуты DAO не могут быть легко переведены друг на друга. Поэтому вам придется добавить дополнительную логику для этого. Это должно заботиться человек в середине, ваш бизнес-уровень.