0

UI プレゼンテーション レイヤー、データ アクセス レイヤー、およびデータ セットを含むコモンズ レイヤーを備えた単純なデータ表示アプリを作成しています。このアプリケーションは比較的軽量 (データの書き込み/更新なし) であるため、ビジネス ロジック レイヤーを記述する代わりに、データ ファサード パターンを使用する方が簡単であると考えました。

質問: Facades に関するこの記事をフォローしてきました: http://msdn.microsoft.com/en-us/library/orm-9780596527730-01-04.aspxと図 4.5 では、Facade は次のように同じライブラリに書き込まれます。サブシステム (私の場合はデータ アダプター)。Data Facade 用の新しい C# クラス ライブラリをまとめて作成するのではなく、このアプローチを採用しますか?

私の UI では、次のように Data Facade を利用しています。

public partial class MyDataApp : Form
{
    DataFacade ApplicationDataFacade = new DataFacade();
}
4

1 に答える 1

0

ファサード パターンの定義によると、ポイントは、ライブラリ全体への単純なインターフェイスを作成するクラスを使用して、複雑なライブラリまたは API を単純なものに単純化することです。

あなたの質問に答えるために、複雑なライブラリが関係している場合、ファサード パターンは理にかなっています。つまり、ビジネス ロジックの作成に代わるものではなく、それを抽象化したものです。レイヤー全体に単一のクラスを使用することを選択した場合、単一のクラスですべての責任を負うことになりますが、これはファサード パターンが求めているものではありません。

プロジェクトが小さいときにこのアプローチを使用しようとするのは理解できますが、メンテナンスで苦労しないように、システムが時間内にどれだけ成長できるかを評価することを忘れないでください。

于 2013-04-29T16:08:50.273 に答える