10

こんにちは、私は階層型開発プロセスにかなり慣れていません。私は現在アプリを開発していますが、今日のテクノロジーのベスト プラクティスやアーキテクチャに関する質問について、いくつかの基本的な質問があります。サービス層として WCF を使用します。可能な限り物事を切り離そうとしていることに注意してください。LINQ TO SQL やエンティティ フレームワークが好きではない理由の 1 つである、上位層の何かが下位層の何かを知る必要はありません。

1) 層の間でデータを渡す最良の方法は何ですか? データセットまたはデータテーブルのいずれかが簡単であることはわかっていますが、この肥大化したデータ構造を階層間で渡すことが最善の解決策になるとは思いません。また、データテーブル/データセットが大きい場合、デバッグが難しくなります。おそらくPOCOオブジェクトの配列が最善の解決策になるでしょうか、それとももっと良い方法がありますか?

2) 次の質問は少しトリッキーです。多くのアプリケーションには、データのさまざまなビューがあります。複数のレポート、さまざまなデータグリッド、および 1 つまたは 2 つのグラフがある場合があります。このためにデータ層をどのように設計しますか? 各テーブルの「Get」タイプの関数を設計してから、それらをビジネスレイヤーのグリッドやレポートなどの便利なビューに結合しようとしていますか、それともビジネスレイヤーで必要な各ビューに特化した関数を持っていますか?

正直なところ、どちらのソリューションも好きではありません。ビューごとに特殊なロジックを決定する場合は、ビューごとに POCO オブジェクトを作成する必要があります (POCO オブジェクトの配列を返すと仮定します)。後でビューの 1 つにさらに列を追加する必要があると判断した場合は、既存のコードを壊すことになります (POCO のインターフェイスを変更するため)。各テーブルのビューを返し、それをビジネス レイヤーで結合しようとすると、非常に面倒になる可能性があります。TSQLには理由があります:)。また、設計によっては必要以上のデータを返す可能性があり、非効率的です。

他にもいくつか質問がありますが、それは後で取っておきます。この投稿が大きくなりたくない:)

ケージ

4

3 に答える 3

5

良い質問です。大事なこと、これ。一般に、階層型ソリューションにアプローチする最良の方法の 1 つは、インターフェイスを調べることです。インターフェースは「チョークポイント」を提供する方法であり、いくつかの有用な目的を果たすことができます。

階層化されたソリューション内で、インターフェイスは層の動作を強制する役割を果たします。期待される一連の動作を効果的に定義することで、層の実装を切り離します。つまり、私の層がインターフェースを適切に実装している限り、実装はまったく気にする必要がないものです。

インターフェイスを定義するときに、層の間で渡されるデータも定義する必要があるため、これを取り上げます (そしてそれは関連しています)。したがって、層の間で何が起こる必要があるかを定義するとき、どのデータが渡されるかを定義することになります。同時に、渡されるデータの厳密なセットを定義します。

分離に関するここでの重要な点は、層の実装に関する情報を層間で渡してはならないということです。つまり、インターフェースを定義し、実装について厳密にすることで、層の実装をゼロから再実装し、インターフェースについてのみ知っていて、問題なく他の実装を置き換えることができるようにすることができるはずです。

これを知っていれば物事は簡単です。通常、Plain Old Objects を使用すると、インターフェイスがクリーンで適切な状態に保たれます。また、データ構造が肥大化するのを防ぎます。また、ある層の別の層への実装に関する情報を使用する誘惑を防ぐ目的にも役立ちます。

もちろん、これを適切に行うには、解決すべき問題を長い目で見ることが役に立ちます。ユーザーが実行したい一連の操作は何ですか? これらの操作は通常、ビジネス オブジェクトが実装するコントラクトを定義するインターフェイス定義に適切にマップされる「動詞」に解決されます。ビジネス オブジェクトが操作するデータセットによって、データベースに必要な一連のビューが定義されます。このようにして、分離をきれいに維持できます。

于 2009-04-23T22:50:37.733 に答える