モデルレイヤーを通じて、コントローラー間でコードロジックを共有していますか？
私が最初にモデルレイヤーを考案したように、それはデータを保持するだけでコードは保持しないことになっています。 WebサービスからDTOを受け取ります。それらは私のModelオブジェクトにマッピングされています。これらのモデルオブジェクトは通常、最終的にViewModelオブジェクトに構成されるか、または専門化されます。ほとんどの場合、コントローラーはいくつかのWebサービスを呼び出し、ビューに渡すViewModelオブジェクトを作成します。実際には、ビジネスロジックを保持するクラスをデータレイヤーの隣のモデルレイヤーに作成する必要がある場合があります。その理由は、このロジックがコントローラー間で共有されるためです。一部のコードがまったく特定されておらず、あまり「構成」を必要としない場合、短い静的メソッドを作成します。これは、一般的に「ヘルパー」と呼ばれるものと理解しています。 "ヘルパー"フォルダーを、"コントローラー"、"ビュー"、"モデル"、"ビューモデル"フォルダーと同じレベルに作成しました。プロジェクト構造の点で正しいですか？分からない。
今度は、コントローラー間でいくつかのコードを共有する必要があり、いくつかの構成が必要になります。たとえば、ある時点で、ビジネスコードは、進行中の計算に関連するさまざまなパラメーターを使用してWebサービスを呼び出す必要があります。これらのパラメータには、セッションキーがあります。したがって、このセッションキーは、処理を開始する前にビジネスオブジェクトに設定する必要があります。
ビジネスコードが仕事を終えた後、コントローラーはモデルをビューに渡します。このモデルは、オブジェクトクラスの点では異なりませんが、さまざまなビジネスオブジェクトによって構築されたデータを使用できます。私の場合、木を示す部分ビューがあります。ツリーのデータは、さまざまな入力を必要とし、さまざまな結果を生成するさまざまなWebサービスから取得できます。結果のモデルのみにオブジェクトタイプの制約があります。
初めに私はこれを持っていました...
コントローラーはWebサービスからデータを取得し、何らかの処理を行ってツリー構造を構築しました。この構造はViewModelオブジェクトに渡され、次にビューに渡されました。
しかし、他のコントローラーからツリー構造を構築するコードにアクセスする必要があるため、このコードを、本能的に「ビルダー」と呼んでいるものに分離しました。このオブジェクトは、BuildHierarchy（）メソッドを呼び出す前に、それを必要とするコントローラーによって初期化されていました。次に、別のWebサービスからの他のデータに基づいて、2番目のツリー構築ロジックを作成する必要があります。しかし、これらのデータを表示するために同じビューを使用したいと思います。
より一般的な観点から、ここに私が現在そのようなコードの構造をどのように想像しているかを示します... 
だから私は2つの質問があります：
- ビルダーパターンについて少し読んだところ、オブジェクトを「ビルダー」と呼ぶべきではなく、このパターンはこのケースにはあまり適していないことを理解しました。達成したいことに対応するパターンはありますか？
- プロジェクト構造では、これらのビジネスオブジェクトを実際にどこに配置すればよいですか？モデルレイヤーに配置してもよろしいですか、それとも別の場所に配置する必要がありますか？
デザインに1層または2層が欠けていると思います。そのため、ビジネスロジックや「ビルダー」コードをどこに配置すればよいかわかりません。サービスと、場合によってはリポジトリ層の追加を検討する必要があります。
サービス層は、コントローラーとモデル/リポジトリの間のインターフェースとなる層です。ビジネスロジックが含まれる場合もあれば、薄いAPIレイヤーの場合もあります。リポジトリ層は、モデルオブジェクトをサービスまたはコントローラーに返す責任があります（これは、あなたが言及したビルダーの概念だと思います）。
追加のレイヤーは複雑さを追加しますが、私は責任を分離することを好みます-通常はそのようにテストする方が簡単であり、後でUIを置き換えたり、Webサービスインターフェイスを追加したりするときに問題が少なくなります。
したがって、理想的な世界では、コントローラーにビジネスロジックやビジネスオブジェクトを含めないでください。これらは完全にドメインモデルレイヤーに配置する必要があります。 Martin Fowlerによる「Patterns of Enterprise Application Architecture」を参照すると、コントローラーはプレゼンテーションレイヤーの一部でさえあるので、入力データをビジネスオブジェクトに渡し、ビューを返す役割を果たします。
あなたが実際にビルダーで何をしているのかはわかりませんが、もしそれが正しければ、ファクトリー・パターンについて考えるべきです。ファクトリーは、どのクラスを使用するかから始まり、どの依存関係を注入するか（構成に関連する可能性がある）から始めて、オブジェクトをどのように構築するかをファクトリー内のロジックによって決定します。