0

Core J2EE Patternsで指定されている DAO パターンを実装しています。私のプロジェクトには 3 つのモジュールがあります:core layerを使用DAO-API layerし、Service Provider DAO-MySQL layerによって実装されます。

TransferObjects の設計と使用について質問があります。

1a)同等の「ビジネス層」クラスと比較して s が非常に冗長であることは正常ですか、TransferObjectそれとも「ビジネス層」クラスTransferObjects ですか?

たとえば、私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);
}

最初の方法を使用する際の欠点は何ですか?

4

1 に答える 1