1
私はいくつかのベストプラクティス/パターンを探しています。 DAOを使用してDBからデータをロードして、ドメインオブジェクトを作成します。私のアプリケーションでは、別のモジュールへの入力として機能する別のオブジェクトに変換する必要があります。 たとえば、顧客は注文のリストを保持するドメインオブジェクトです。これをオブジェクトcustomerorderに変換する必要があります。現在オブジェクトを変換するパターン
Public class Customer {
String customerid
List<Order> orders
}
Public class Order {
Integer id
Date orderDate
}
/** Transformed objects **/
public class CustomerOrder {
string customerid
Integer orderid
}
私はDTOクラスを必要としない、変換をCustomerOrderがオブジェクトのリストと簡単なためインタフェース
Public interface CustomerDTO {
List<CustomerOrder> getData(Date date)
}
Public class CustomerDTOImpl implements CustomerDTO {
Private Customer customer
Public CustomerDTOImpl(Customer customer) {
this.customer = customer
}
Public List<CustomerOrder> getData(Date date) {
..... Code to loop through orders and create and return a list with matching order dates
}
}
を実装する具象クラスを返すようにする方法を持っているインタフェースCustomerDTOを持っています私の変換は非常に複雑で、変換ロジックを別々のオブジェクトに分けて保存したいと考えています。 最初はすべてのオブジェクトをループして変形したオブジェクトを作成するトランスフォーマークラスがありましたが、それはこのDTOの優れた設計と思想ではないと思います。しかし、私はそれを行うより良い方法があると信じています。
また、いくつかのオブジェクトでDTOパターンを使用できるようにする必要があります。この顧客では、そのようなオブジェクトの1つだけでしたか？私はそれぞれの変形されたオブジェクトに変換する必要があるような難しいオブジェクトのような20を持っています。
ベストプラクティスとパターンに関する考えは非常に役に立ちます。また、私はそれらをより良くスケールアップするために使用できるジェネリックスもあります。
おかげ Javid
データパターンがうまく設計されていないという事実を回避しようとしているという事実に対処するためのデザインパターンが必要です。あなたが実装しようとしているユースケースについては？私はあなたがそれに固執していると思っています。それを機能させるのはあなたの役割ですか？これです。これが私が大企業のJavaプロジェクトをもう利用しない理由です。 アーキテクチャをリファクタリングして他のモジュールが必要とするインターフェイスをデータオブジェクトに実装できるようにすることをお勧めします。それでも問題が解決しない場合は、アダプタパターンを確認してください。 –
@BenTaitelbaum私は部分的に同意します。データモデルは完全には設計されていませんが、変換はかなり複雑です。変換された最後のオブジェクトを反映するようにデータモデルを変更しないことによって、DAOまたはドメインモデルを変更することなく、将来の変換ロジックの変更をサポートできます。私はアダプターのパターンを調べます。私のDTOImplクラスがすでにそうしているようです。感謝。 – user320587