2

n層アーキテクチャについて質問があります。似たような質問がたくさんあるので、この質問をする前にじっくり考えました...しかし、文字通り1日半見て、これらの他の答えを読んだ後、私はまだ確信が持てません。一見似ているように見えるさまざまな用語と異なるアプローチは、私を混乱させました。

異なるクラスライブラリにBLLとDALがある場合、BLLとDALの間で通信する1つの方法は、BLLとDALの両方によって参照される別の別個のDLLで定義されたDTOのよ​​うなインターフェイスを利用することです。BLLの私のドメインモデルエンティティはこのインターフェイスを実装し、DALのORM生成オブジェクトも実装します。ビジネスエンティティを保存するために、それらをDALに渡すことができます。これにより、共有インターフェイスが実装されているため、正常に受け入れられます。このインターフェイスを実装するオブジェクトをBLLに戻すこともできます。これは、BLLとDALの両方が基本的なインターフェイスを認識するだけでよく、お互いに具体的な実装を認識する必要がないため、合理的と思われます。

私の質問は、反対側にオブジェクトを作成するための最良の方法は何ですか？たとえば、IPersonを実装するBLLにPersonオブジェクトがあり、IPersonも実装するDLLにPersonDataObjectなどがある場合、IPersonのパラメータを受け取るDALのメソッドにPersonを渡し、次にDALでI ' d永続化するには、PersonDataObjectを再構築する必要があります。これも最良の方法ですか？

申し訳ありませんが、私はかなり混乱しているので、おそらくこれをあまりよく説明していません。ダミーの回答のベストプラクティスをいただければ幸いです。

4

3 に答える 3

5

一般的に、BLL内のオブジェクトはインターフェースを消費します-それらを実装しません：

たとえば、IPersonを実装するBLLにPersonオブジェクトがあり、PersonDataObjectまたはIPersonも実装するDLLにあるものがある場合

「人」を例にとると、人に関連するさまざまなデータ操作（1人の人のすべてのデータの取得、多くの人の浅いデータの収集、CRUD操作、検索など）について考えてから、インターフェースを設計します。論理的なグループ化（インターフェイスの分離の原則を参照）。

インターフェイスは、BL中心の観点からの操作、または「サービス」ベースの観点からの操作を表す場合があります。

とにかく、あなたの特定の質問に答えるために...

共通アセンブリでDTOに相当するものを定義し、別のアセンブリでもデータインターフェイスを定義します。したがって、4つのアセンブリがあります。BL、データアクセスインターフェイス定義、インターフェイス実装、および共通です。すべてのアセンブリは共通のアセンブリを参照します。

私はC＃.Netで作業しており、DTOを構造体として定義しています（ただし、クラスを使用することもできます）。そして、これらのすべてのプロパティは読み取り専用です-コンストラクターでデータをそれらにフィードします-このようにして、DTOは事実上「ダム」な情報のエンベロープになります。

于 2010-06-27T00:03:25.923 に答える
2

n層アーキテクチャに従う一方で、BLとDALの間でデータオブジェクトを共有することは非常に一般的です。場合によっては、同じデータオブジェクトをUIレイヤーでも使用できます。

通常、私はすべてのモデルオブジェクトをインターフェイスとして格納するデータモデル（またはデータオブジェクトまたはドメインモデル、名前は何でも）アセンブリを持っています。あなたの人々の例をとって、私はモデルアセンブリでIPeopleインターフェースを作成します。DALはIPeopleのインスタンスをBLに返します。BLはこのインスタンスを消費し、必要に応じて、ビジネスロジックを適用した後にこれをUIレイヤーに渡します。

于 2010-06-27T07:00:14.070 に答える
1

ドメイン駆動設計とリポジトリパターンのためのGoogle。それはあなたがあなたのアーキテクチャでその方向に向かっているように思われます、そしてシナリオがそれを正当化することに応じて、私はより複雑なコードでこのアプローチを使うでしょう。

于 2010-06-25T23:01:34.323 に答える