3

数年前、このファイルは同じ部分クラスをラップしていましたが、ビジネスロジックコードを別々の.csファイルに実装するように言われました。したがって、次のようにビジネスレイヤーからメソッドを呼び出すことができます。

using(FooPartialDisposableClass partialClassInstance = new FooPartialDisposableClass ())
partialClassInstance.BusinessMethod();

Ok。だから今、私はファサードパターンを使用している今回だけ同じことをしています。このソリューションは、より多くのコードを記述しなければならず、保守性が低い場合でも、より良いアプローチのように思われます。

さて、私の質問は...部分的なクラスのアプローチに従うのは正しいでしょうか？

PS：これらのビジネスロジックメソッドを使用するレイヤーからこのレイヤーを分離するためのインターフェイスと依存性注入についても考えましたが、ここでどのように機能するかを考えると、ノーノーです：S

4

3 に答える 3

7

Partial classesOOP設計上の特徴ではありません。それらは単なる「コードレイアウト」のものであり、コードデザインの代わりになることはできません。

必要に応じて、これは単なるコードレイアウト/配布機能です。

Facadeデザインはとは異なります。パターンがプロジェクトのニーズに最も適して DIいると思われる場合は、それを続行してください。Facade

クラスのファイルが大きくなりすぎた場合や、チームメンバーが異なれば、その別の部分に変更を加えたい場合に備えて、部分的なクラスを使用しますFacade。この場合、（チーム内の責任の分散に基づいて）異なるファイル間でファイルを分散して、コードの管理を容易にし、可能な限り競合を回避します。

于 2012-05-30T11:10:09.590 に答える
2

コードをパーシャルで分離する 2 つの理由を見つけました。

  1. そのため、コードのチェックイン中に 2 人 (またはそれ以上) の開発者が衝突することはありません。紛争解決は吹く！

  2. 生成されたコード。メインの部分クラスにコードを生成し、カスタム オーバーロード用に別の部分を作成します。完璧に動作します！

私はビジネス ロジックとデータ レイヤーを別々のクラスに分離することを信じており、これらのレイヤーでは主に静的メソッドを使用しています。コードが増えて保守性が低下する可能性があるかどうかは本当にわかりません。

于 2012-05-30T11:17:59.880 に答える