n 層ソリューションを作成するとき、ビジネス オブジェクトを公開したくありませんが、代わりに DTO を使用します。一方で、オブジェクトを二重に定義したり、常にコピー コードを記述したりしたくはありません。
ここでの私の考えは、必要なすべてのフィールドとプロパティを含み、ロジックを含まない (状態のみ) DTO を作成することです。
次に、これらの DTO からビジネス オブジェクトを派生させ、ビジネス ロジックを使用してそれらを拡張し、DTO 基本クラスのプロパティを操作します。これらのオブジェクトは、使用される ORM (NHibernate) で永続化されるオブジェクトでもあります。
このアプローチを使用すると、サーバー側でビジネス オブジェクトを処理し、クライアントに直接渡すことができます (これらは派生しているため、ダウンキャスト可能です)。ビジネス ロジックをそのように公開して、多くのコードを節約する必要はありません。
そのアプローチは賢明だと思いますか。
よろしく、
セバスチャン
次の点を考慮してください。
「...、DTO がドメイン オブジェクトを認識しないようにすることで、さまざまなコンテキストで DTO を再利用できるようになるためです。 同様に、ドメイン オブジェクトに DTO を認識させたくありません。これは、DTO を変更するとコードを変更する必要があることを意味する可能性があるためです。ドメインロジックで、メンテナンスの悪夢につながります。
最善の解決策は、ビジネス オブジェクトから DTO を作成する、またはその逆のアセンブラー パターンを使用することです。Assembler は、エンタープライズ アプリケーション アーキテクチャのパターンでも言及されているMapperパターンの特殊なインスタンスです ...."
パターンと実践から: データ転送オブジェクト
また、私自身は使用していませんが、AutoMapperもチェックしてみてください。
私には合理的に聞こえます。Linq to SQL では、ビジネス オブジェクトは部分クラスを使用して DTO から派生します。
「それから、それらの DTO からビジネス オブジェクトを派生させます」