1

まず第一に、プロジェクトのレイアウトに関して万能のサイズはないことを理解していますが、mvc に移行しているので、しっかりした基盤から始めたいと思っています。

現在、私はこれまでのところ、asp.net mvc プロジェクト構造と n 層および依存性注入 (ninject) に本当に苦労しています。私は、スポーツ ストアを 2 つのプロジェクトに分割する Pro Asp.net Mvc 3 Framwork を読んでいます。

これまでのところ、私のプロジェクトは以下のアウトラインのようになるはずだと思います

  • Web UI (Asp.Net Mvc)

  • サービス層

    • サービス インターフェイス (要約)
    • サービス (サービス インターフェイスの具体的な実装)

  • データレイヤー

    • データ インターフェイス (要約)
    • データ (サービス インターフェイスの具体的な実装)

では、私のエンティティ/モデルはどこにあるのでしょうか? それらを Web UI から移動する必要があると思いますが、どこに収まるかは完全にはわかりません。

Microsoft のプロジェクト Silk が最初に行ったように、レイヤーごとに個別のエンティティを作成し、automapper のようなものを使用してデータ エンティティとサービス エンティティ間をマッピングしますか (これは、目的の分離を達成するためのかなりのオーバーヘッドのようです)。または、他のレイヤーが参照するエンティティレイヤーになります。このレイヤーには、強く型付けされたデータセットまたは Plain Old C Objects のいずれかが含まれる可能性があり、インフラストラクチャのタイトルの下にある可能性があります。これらはレイヤー間で受け渡され、ビュー モデルを介して Web Ui レイヤー内でカスタマイズされます。

また、Ninject を使用している場合は、コンポジション ルート (この場合は Web Ui プロジェクト) 内で構成する必要があります。

これは、私がアクティブにしようとしている分離を無効にするすべてのプロジェクトへの参照を追加することを意味します。

4

2 に答える 2

2

論理層！=物理層。構造が単純でプロジェクトが少ないほど、管理が容易になります。

それで、私は通常1つのWebプロジェクトを持ち、論理レイヤーとして名前空間を使用します。通常、エンティティの動作を管理するために、UI表示用のビューモデルとドメインモデルが必要です。

于 2012-10-24T14:00:18.893 に答える
0

では、私のエンティティ/モデルはどこにありますか？

彼らに彼ら自身のプロジェクトを与えなさい。

レイヤーごとに個別のエンティティを使用し、automapperのようなものを使用して、Microsoftのプロジェクトsilkが最初に行ったようにデータエンティティとサービスエンティティの間をマッピングしますか？

多くのマッピングを行わないようにしてください。ビューモデルにマップする必要があるのは非常に自然なことですが、エンティティのすべてのプロパティをビューモデルにコピーする代わりに、エンティティをビューモデルのプロパティとして公開し、UI固有のプロパティを追加するだけです。UIに必要なのがそのエンティティだけの場合：ビューモデルを使用しないでください。この余分なマッピングは、アプリケーションの保守性に余分な負担をかけるだけです。

また、DAからエンティティにマップする必要がないようにしてください。代わりに、POCOエンティティをEntity Framework、LINQ to SQL、およびNHibernateサポートとして使用してください。繰り返しますが、この余分なマッピングはおそらく努力する価値がありません。

私がアプリケーションで使用するマッピングは、多くの場合、別のレベルにあります。私はコマンドとクエリを中心にビジネスロジックを設計しており、これはプレゼンテーション層にも非常によく変換されます。MVCのバインド機能を使用して、コマンドをビューに直接表示し、フォームのプロパティをコマンドにバインドして実行することができます。少し余分な作業があれば、MVCを使用すると、（ビュー内でも）完全にコンパイル時をサポートすることもできます。

于 2012-10-24T14:08:52.917 に答える