400を超えるストアドプロシージャを持つpostgresデータベース（npgsql）を備えた3層アーキテクチャに基づくアプリケーションがあります。次に、MVC3フレームワークを使用して同じアプリケーションを開発したいと思います。
これらのストアドプロシージャで既存のデータベースを使用するための最良の方法を知りたいのですが、コードファーストアプローチ（http://weblogs.asp.net/scottgu/archive/2010/08/03/using-）に出くわしました。 ef-code-first-with-an-existing-database.aspx）が、それが最善の解決策であるかどうかを知りたい。
また、Razorの利点についても読みましたが、私のアプリケーションにはDataGridViewsとTabContorlsがたくさんあるので、Razorを使用するのは簡単でしょうか？
既にあるようなもの (http://npgsql.projects.postgresql.org/) を使用することをお勧めします。その後、既存のフレームワーク/インフラストラクチャ (既存のアプリケーションからデータベースにクエリを実行する方法) を活用できます。
第二に、DataGridViews と TabControls を使用している場合、ASP.NET MVC は実際にはサーバー コントロールで動作しません。グリッドを提供する HtmlHelper を取得するか、自分で作成する必要があります。
私が尋ねる必要があると思う質問は、なぜ MVC と WebForms 4.0 のどちらに行きたいのかということです。
最初に、MVC3 を使用して既存のアプリケーションを開発するために必要なリファクタリングまたは変換レベルを決定する必要があります。
次の理由により:
テクノロジーとしての MVC の使用は、OOP 設計または通常の OOP としての DDD と何らかの関係があります。どちらのアプローチでも、メイン レイヤーは DB ではなくドメイン モデルであるため、すべてのストアド プロシージャをドメイン モデル内のビジネス ロジックに変換する必要があります。それ自体または既存の DB を使用する場合、MVC を使用する大きな利点の 1 つが失われます。
プレゼンテーション レイヤーで MVC を操作する場合、DataGridViews または TabContorls を操作することを考慮しないため、それらもスローする必要があり、それらを再利用する解決策はありません。
最後に、MVC を使用する主な利点は、ユニット テストの機能と、MVC が提供する高度な保守性です。
したがって、何を保持し、何を破棄するかを決定するには、達成したい変換のレベルをよく考える必要がありますが、プロジェクト全体を本当に再構築しない場合は、MVC に変換しないことをお勧めします。プロジェクトをそのままにして、リファクタリングして既存のアプローチを強化するだけです