Core J2EE Patternsで指定されている DAO パターンを実装しています。私のプロジェクトには 3 つのモジュールがあります:core layer
を使用DAO-API layer
し、Service Provider DAO-MySQL layer
によって実装されます。
TransferObject
s の設計と使用について質問があります。
1a)同等の「ビジネス層」クラスと比較して s が非常に冗長であることは正常ですか、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
です。また、Core J2EE Patternsの「Example 9.5 Customer Transfer Object」ではCustomer
、.TransferObject
DAO-API layer
また、2 つのクラスを持つことで、から完全に独立し、別のモジュールとして提供できるという利点も見core layer
られます。これは、エンド ユーザーにはわかりません。
=> 1b)しかし、おそらく myDAO-API layer
は my の一部でcore layer
あり、?でCustomer
ある必要があります。TransferObject
=> 1c)または、コア ビジネス レイヤ クラスとその転送オブジェクト間の冗長性を回避するために見逃しているものはありますか?
2) DAO メソッドを呼び出すときに s をパラメーターとして使用しないことは合法ですか? TransferObject
例えば:
public interface CustomerDAO {
public Collection<CustomerTO> getCustomersByNameAndCity(String name, String city);
}
または、常に次のようなものを使用する必要があります。
public interface CustomerDAO {
public Collection<CustomerTO> getCustomersByNameAndCity(CustomerTO to);
}
最初の方法を使用する際の欠点は何ですか?