3

私がほぼ完成した最近のプロジェクトでは、Web/サービス層からの相互作用の最上位層として XXXManager クラスを使用するアーキテクチャを使用しました。

たとえば、いくつかの多様なデータ ソースからシステムにデータをインポートする、スケジュールに基づいて実行される Windows サービスがあります。このサービス内では、CPImportScheduleManager、CPImportProcessManager など、いくつかの「マネージャー」クラスが呼び出されます。

現在、これらの Manager クラスは、Web/サービス レイヤーで使用するためにメソッドをチェーンに渡すだけではありません。たとえば、私の UserManager.Register() メソッドは、下位レベルのアセンブリを介してユーザーを永続化するだけでなく、WAP プッシュをユーザーに送信し、使用される携帯電話などを決定します。

このタイプのアーキテクチャーは、OOP を手続き型モデルに適合させようとする一般的な手段であることが示唆されています。私は彼らの要点をここで見ることができますが、私が不思議に思っているのは、このトップ レベルのクラス セットを使用すると、コードを書き直す必要なく、Web/サービス レイヤーが同じ共通メソッドを簡単に呼び出すことができるということです。したがって、ある時点でユーザーを登録する Web サービスを作成したい場合は、すべてのロジックを再度書き直さなくても、 UserManager.Register() メソッドを再度呼び出すことができます。

私は自分自身を説明するのに最適な人物ではない.

乾杯、クリス。

4

2 に答える 2

7

マネージャーは、特定のエンティティセットのワークフローまたは複雑なタスクを処理するサービスでよく使用される命名戦略です。しかし、それが仕事を成し遂げるなら、それは必ずしも悪いことではありません。

私が持っている重要な質問は、マネージャーの下で何が起こっているのかということです。ユーザーの登録など、プロセスのワークフローを単純に調整する場合は、別の名前のコントローラー（MVC）になります。ただし、それらに多くのビジネスロジックが含まれている場合（これは、エンティティまたはエンティティのセットの状態に応じた条件付きロジックを意味します）、このロジックを明示的にすることができるかどうかを注意深く調べます。自分のクラスを所有するか、適切な責任を持ってクラスに移動します。

更新：その音から、あなたは一般的に正しい考えを持っています。WebService、Webformなどで使用されているかどうかを気にしない、ビジネスプロセスの調整を処理する一連のクラスがあります。次に、この上にWebServiceレイヤーを追加し、これらのクラスを利用したいと言っています。これはGoodThing（tm）です。

于 2008-09-26T12:20:45.020 に答える
0

その設計に対するあなたの動機は良かったようですね - コードの再利用。いくつかの点で、Martin Fowler の Service Layerに動機が似ています。ただし、これらの Manager クラスにあまりにも多くの責任を積み上げている可能性があります。おそらく、インフラストラクチャの問題 (WAP プッシュ、ユーザーの永続性) をドメインの問題 (ユーザー登録) から分離します。この関心の分離により、再利用性がさらに向上し、保守性も向上します。

于 2008-09-26T12:30:24.483 に答える