4

DTO/BO について私が疑問に思っていることの 1 つは、いつ DTO を渡す/返すか、いつ BO を渡す/返すかということです。

私の直感によると、常に NHibernate を BO ではなく DTO にマップし、常に DTO を渡したり返したりするように指示されています。その後、ビジネス ロジックを実行する必要があるときはいつでも、DTO を BO に変換していました。

これを行う方法は、BO に、DTO と BO の両方が唯一の引数として実装するインターフェイスの型 (必要なフィールド/プロパティを定義する) であるパラメーターを受け取るコンストラクターを持たせることです。

次に、コンストラクターで DTO を渡すことで BO を作成し (両方とも同じインターフェイスを実装しているため、両方とも同じプロパティを持っているため)、その BO でビジネス ロジックを実行できます。BO を DTO に変換する方法もあります。

しかし、人々が BO のみを操作し、バックグラウンドで DTO のみを操作しているように見える場所も見てきましたが、ユーザーには DTO がないように見えます。

常に BO を使用する場合と比較して、このアーキテクチャにはどのような利点/欠点がありますか?

私は常に DTO または BO のいずれかを渡したり返したりする必要がありますか、または組み合わせて一致させる必要がありますか (混合と一致は混乱を招く可能性があるようです)。

4

3 に答える 3

2

それはあなたが何を達成したいかによります。私が自分で何をしているのかをお伝えできます - DTO と BO の両方を NHibernate にマッピングしていますが、DTO は不変としてマッピングされているため、BO を使用せずに誤ってデータベースを更新することはありません。

WebServices でアクセス可能なすべてのクエリは、DTO を返したり受け入れたりします。

DTO から更新するときは常に、UnitOfWork を実行します。ここで、BO をロードし、DTO からプロパティを更新して、まだ有効な場合は再度保存します。

クライアントで、クライアントが変更する必要があるときはいつでも、DTO から BO を作成します (AutoMapper はここでは間違いなく有効な選択です)。BO には、NHibernate が行うのと同様に、BO を作成するためにすべての引数を取る ctor があります。

利点は次のとおりです。 * ネットワーク上を移動するデータ量を完全に制御します (DTO は通常フラット化されるため、関連付けられたクラスの Id のみが最初の呼び出しで送信されます)。* 両方で同じプロパティを持つ必要はありません * 必要に応じて遅延読み込みを組み合わせて使用​​できます * BO でそれらを作成せずに、DTO でスカラー クエリやその他の計算されたプロパティを利用できます。* さまざまなシナリオで、BO ごとに複数の異なる DTO を使用できます。

だから、それはミキシングとマッチングとしての資格があると思いますが、私がどこで何をするかについての明確なガイドラインがあります:-)

お役に立てれば。

于 2011-01-09T22:35:37.917 に答える
0

多分あなたはこれを見つけるでしょう: http://automapper.codeplex.com/ も便利です。

于 2011-01-09T10:16:05.793 に答える
0

これがかなり古い質問であることは承知していますが、この件について私の「10 セント」を差し上げましょう。

MVC プロジェクト (Entity Framework または NHibernate を使用する場合でも) で作業する場合、私は POCO を永続化に使用し、DTO/ViewModels を中間作業に使用します。オブジェクト間の関係を決して公開しないでください。

これは「銀の弾丸」のように聞こえるかもしれませんが、少なくともしばらくの間は機能しています。

(いくつかの英語の間違いを許してください =) )

于 2015-06-30T18:21:20.867 に答える