上位アプリケーションでデータを渡す

Question

n 層アプリケーションのレイヤーにデータを渡すにはどうすればよいでしょうか?3つの異なる方法を計画しました。

A)汎用 .net オブジェクト 汎用データ テーブル、ハッシュテーブル、汎用データセット、文字列、整数など...次に、データセットを使用してビジネス オブジェクトを入力し、UI レイヤーに送信します。

代替テキスト http://img11.imageshack.us/img11/460/generic.png

http://dabbleboard.com/draw?b=eiu165&i=26&c=54eef6f1ac01f03c85919518f4a24e798e57e133

プロ- 追加のレイヤーは必要ありませんコン- ビジネスレイヤーで汎用データセットとテーブルを操作する必要がある

B)他のレイヤーが参照するエンティティ レイヤーを使用します。このレイヤーには、厳密に型指定されたデータセットまたはプレーンな古い C オブジェクトが含まれます。オブジェクトの大部分はコンテナ データであり、ロジックはほとんどありません。これらは UI レイヤーに送信されるのと同じオブジェクトになります。

代替テキスト http://img8.imageshack.us/img8/6454/entities.png

http://dabbleboard.com/draw?b=eiu165&i=6&c=d0c2b346894a96b12bd3867f630e474a2af098fa

プロ- すべてのレイヤーで同じクラスを操作するコン- すべてのレイヤーにentities.dllへの参照を追加する

C)データ アクセス レイヤーで定義されたデータ転送オブジェクト (コンテナ オブジェクトのみ) を使用します。次に、それらのオブジェクトを使用して、UI レイヤーに送信されるビジネス オブジェクトを埋めます。

代替テキスト http://img43.imageshack.us/img43/1236/transferp.png

http://dabbleboard.com/draw?b=eiu165&i=27&c=f886efa3f9d5eb4b45ddb02361c79cddaec0a9b

プロ- ビジネス層はジェネリッククラスを扱う必要がありませんコン- 2 種類のオブジェクトを扱う場合、ビジネス オブジェクトを転送オブジェクトでハイドレートする必要があります。

私たちは職場で話し合いをし、コミュニティが何を考えているかを知りたかったのです。ドーブルボードへのリンクも追加しました。編集せずにコピーして作成してください。
ありがとう

Answer 1

あなたはすべての層を意味する、の階層化のアプローチを使用している場合は、同じプロセス空間で実行する（本質的）であり、何のマーシャリング/連載がゆえありません、私が作成したアプローチBでいいよ別のプログラムのすべての側面が依存するあなたのエンティティのためのモジュール、およびそれに結合ます。

しかし、あなたはあなたのタイトルが示唆するように、の階層のアプローチを使用して交差しているプロセスおよび/またはネットワーク境界がある意味している場合は、

、私はあなたがアプローチC.で行くことをお勧めしたいです本当に周りのインスタンスを渡していない「再、あなたはコピーを渡しているので、あなたが得るすべての利点は言う、のために観察可能なオプション、とにかく失われたMVCアプローチのように、同じオブジェクトを結合します。すべての周りの同じクラスを使用しようとするよりも良いが、すべての階層レベルでのデータのAPIを定義します。

Answer 2

グレート質問 - いつものように、答えは「それが依存」である必要があります。

。

アプリケーションの種類、および（データベース・エンティティに多くを対応すなわち易しく書き直さダウンビジネスオブジェクト）オブジェクトを転送することとは対照的に、ビジネスオブジェクト（エンティティ）を持っている必要が本当にあるかどうかを。

伝統的に、私は純粋にパフォーマンス上の理由から、あなたは常に汎用的なデータセット（またはデータテーブル）の必要性を持っていると主張しているだろう。大きなセットを表示、で動作する、または操作する必要があるたびに、ビジネスオブジェクトの多数のインスタンス化の伝統的な厳格なOOの方法が失敗します。

私は、LINQ to SQLはで動作するように始めて以来、

しかし、私のパラダイムが変わってきました。ビジネスオブジェクト、転送オブジェクト、および一般的なデータセット - LINQのモデルはすべてすることができるので、まったくこれの必要性は、もはやありません。私は、これは本当に大規模なアプリケーションでどのように動作するかも、とLINQのモデルからフロントエンドのコードを分離する必要性があるべきかどうかはまだ模索していません。私は本当に答えいずれかの方法を見つけることなく、同僚とそれについての議論を持っていた。

Answer 3

私はオプション C が好きですが、次の 2 つの理由で一時停止します。

1. 私はあまりにも多くの場所にその財産が何であるかについての知識を広めなければなりません。
2. DTO はシリアル化可能でなければなりません。これはひどいことではありませんが、それでも考慮すべき点です。

Answer 4

私はすべての3層が同じアプリ内に存在すると仮定しています。 Javaでは、少なくとも私は、データアクセスのためにHibernateを使用しましたし、すべての層でそれらのデータ豆を使用しました。 （オプションB）それはあなたの層にあなたのエンティティを再利用できるようにするには理にかなっています。