.net webforms アプリを書いています。ユーザー、予約など、いくつかのクラスがあります。現時点では、これらのクラスを管理する、bookingManager などのマネージャー クラスがいくつかあります。たとえば、新しい予約を作成するときは、bookingManager で add メソッドを呼び出し、予約を渡します。次に、予約が有効であることを確認し、競合していないことを確認し、競合していない場合はデータベースに追加します。他のクラスにも同様のマネージャーがありますが、ユーザーマネージャーなどは、ユーザーを取得してDBに追加するだけではありません。だから私の質問は、これはこの種のことを行うための最良の方法ですか、それともこれにより適したパターンまたは方法はありますか?
4 に答える
あなたが説明しているように、あなたはすでにパターン、3層パターンを使用しています:)
これは、アプリケーションでコードを 3 層にする必要があることを示しています (名前が示すように)。
プレゼンテーション層: データを表示するコードを記述する場所 (ASPx/winforms/etc)
アプリケーション層 : すべてのビジネス ロジックを配置する場所 (マネージャ クラスで行っていること)
データ層 : データベースへの実際のアクセスを行う場所。
このパターンに従うと、複数のアドレスを持つクライアントのようなものがあり、クライアントが 1 つのテーブルに格納され、アドレスが別のテーブルに格納されている場合に役立ちます。プレゼンテーション層では、アプリケーション層のメソッドを呼び出してクライアントを保存するだけです。アプリケーション層でデータをチェックし、データ層で 2 つのメソッドを呼び出します。1 つはクライアントを保存するためのもので、もう 1 つはアドレスを保存するためのものです。
複数の住所を持つサプライヤーがいる場合は、データ層で同じ方法を使用してそれらを保存できます。
これは、複雑なオブジェクトがある場合に役立ちます。ただし、ほとんどのオブジェクトがシンプルである場合は、このパターンが適切かどうかをよく検討することをお勧めします。
マネージャーがUIとドメインクラスの間のコントローラー/プレゼンターのようなものである場合、それは薄いレイヤーであるべきだと思います。数行のコードが含まれている必要があります。次に、ドメイン サービスまたはサービス クラスが残りの作業を処理する必要があります。例えば :
UI:
buttonClicked(Eventargs...)
{
presenter.Save();
}
プレスネッター:
public void Save()
{
bookingService.Save(view.Name,view.DateTime...)
}
サービス :
public void Save(string name,DateTime dateTime...)
{
//do operations or call repository/Dao classes to save
}
小さなアプリケーションではやり過ぎかもしれませんが、大きなアプリケーションでは保守性が向上します。Domain Driven Design book と Domain Service classes を見ることができます。
特に、あなたが言及した予約マネージャーなど、システムのいくつかの異なる側面を管理する場合は特に、マネージャークラスを持つことに問題はありません。その場合、予約についてユーザーに知られたくない、または予約がユーザーについて知りたくないかもしれませんが、これは当然システムの詳細に依存します。
マネージャの優れた点は、複数のコンポーネントに依存するおそらく複雑なロジックを格納するための中心的かつ論理的な場所を提供することです。また、データクラスをそのように使用して、それらのクラスの結束を高めることもできます。
マネージャーの「あまり良くない」点は、システム内の他のコンポーネントと適度に密接に結合されている可能性が高い別のコンポーネントがあることです。これの長所と短所のバランスを取り、アプリケーションにとって最も理にかなったアーキテクチャを選択する必要があります。
そのようなクラスには、Save、Delete、および Update メソッドを実装する方が常に良いと思います。そのようなもののための Manager クラスは間違いなくやり過ぎです。たとえば、予約クラスに実装されたこれらのメソッドは、同じ検証を行い、コードにクラスを追加しすぎることによる複雑さを回避できます。