Я реализую шаблон DAO, как указано в Основные шаблоны J2EE. В моем проекте у меня есть 3 модуля: core layer, который использует DAO-API layer, который реализован моим Поставщик услуг DAO-MySQL layer.
У меня есть вопросы по дизайну и использованию TransferObjects:
1a) Нормально ли, что классы TransferObject сильно избыточны по сравнению с эквивалентными им классами "бизнес-уровня", или классы "бизнес-уровня" являются TransferObject?
Например, если в моем 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 Объект передачи клиента» Основные шаблоны J2EE , похоже, это только один класс Customer, который является TransferObject.
Я также вижу преимущество в том, что наличие двух классов позволяет моему DAO-API layer быть полностью независимым от core layer и предоставляться как отдельный модуль, о котором конечные пользователи даже не узнают.
=> 1b) Но, может быть, мое DAO-API layer должно быть частью моего core layer, а Customer быть TransferObject?
=> 1c) Или я что-то упускаю, чтобы избежать избыточности между основным классом бизнес-уровня и его объектом передачи?
2) Можно ли не использовать TransferObject в качестве параметров при вызове методов DAO? Например:
public interface CustomerDAO {
public Collection<CustomerTO> getCustomersByNameAndCity(String name, String city);
}
Или я всегда должен использовать что-то вроде:
public interface CustomerDAO {
public Collection<CustomerTO> getCustomersByNameAndCity(CustomerTO to);
}
Каковы недостатки использования первого метода?
