MVC、Ninject、NHibernate (これらのテクノロジを初めて使用) を使用して n 層アプリケーションをセットアップしています。わかりやすくするために、層は「データ」層、「サービス」層、および「Web」層です (すべて別のプロジェクトです)。
MVC では、"Models" フォルダーにモデルがあります。強く型付けされたビューを作成し、一般的に MVC の哲学を維持するには、ここにモデルを配置する必要があるようです。
ただし、NHibernate では、マッピングを実行し、NHibernate が実際のオブジェクトをインスタンス化してサービス層に返すことができるように、「データ」層にもモデルが必要です。
プロジェクト間でクラスを複製することはあまりDRYではなく、それらを独自のライブラリに抽象化することはMVCではうまくいかないようです（実際にも哲学にもありません）。
何かご意見は？O/RM オブジェクトと MVC モデルをどのように構築しますか?
データモデルは独自のものです。MVC のモデルは別のものです。これは、表示しようとしているもののモデルであり、データ モデルである場合とそうでない場合があります。あなたはデータモデルであり、レイヤーを超える場合と超えない場合があります。
たとえば、標準のサインアップ フォームを考えてみましょう。データ モデルには、ユーザー名、パスワード、ログイン履歴クラスの配列、アクティブであることを示すフラグ、およびその他多くのものを含めることができます。MVC のモデルは、ユーザー名とパスワードのみを気にする場合があり、ユーザーはパスワードを 2 回入力する必要があります。データ モデルに 2 つのパスワード フィールドが本当に必要ですか? いいえ。ただし、MVC のモデルはそうです。したがって、2 つの異なる生き物。
Entity Framework モデル/クラスをデータ層に保持し、MVC プロジェクトの Models フォルダーをプレゼンテーション モデルとモデル バインダーに使用します。
NHibernateがあるため、すべてのモデルをデータ層に保持しています。プレゼンテーションをクリーンに保つための優れた方法については、S＃arpアーキテクチャをご覧ください。ビューを厳密に型指定するために、モデルをWebプロジェクトに物理的に配置する必要はありません。
ここでの DRY 原則については正しいです。LINQ-to-SQL オブジェクトをビジネス オブジェクトから分離したままにしており、重複があり、気分が良くありませんが、簡単な回避策はないようです..
この決定には苦労しましたが、MVC Storefront を構築しているときに Rob Conery のブログを見て、最終的にこの方法 (ORM オブジェクトとビジネス オブジェクト) に進むことにしました。
MVC では、"Models" フォルダーにモデルがあります。強く型付けされたビューを作成し、一般的に MVC の哲学を維持するには、ここにモデルを配置する必要があるようです。
どんなモデルもあなたの望むものにはなりえません。必要に応じてプレゼンテーション モデルを引き続き使用しますが、ビューで休止状態のエンティティを使用することに異議はありません。
NHibernate では、セッション自体がデータ層であるため、実際にはデータ層は必要ありません。
サービス層は有効なアイデアのように思えますが、この層に複数のクライアントを持つことを計画している場合に限られます。
それ以外の場合は、プロジェクトを 1 つしか持たず、名前空間を使用してレイヤーを分離します。ビルドが速くなり、展開が容易になります。