mvc3アプリケーションでコードを整理するためのベストプラクティス

Question

学生管理のmvc3アプリケーションを1つ作成したいと思います。 私はいくつかのオープンソースプロジェクトを見てきました。 彼らは、コアのようなソリューション構造を使用しています。 このような構造を使用する理由はありますか？

Answer 1

前述のように、論理階層は、BusinessLogic（エンティティ、検証など）、データ（お気に入りのORM）、およびプレゼンテーション（MVC）の少なくとも1つに分ける必要があります。

しかし、始めようとしているのであれば、SOLIDアーキテクチャのすべての高度な概念を組み込むのは少し難しいかもしれません。

論理層を分離することは、必ずしも別々のプロジェクトを意味するものではありません。標準のMVC3テンプレートは、これを "Models"フォルダで示しています。これに追加されたすべてのエンティティは、Myproject.Modelsという名前空間になります。後でモデルフォルダのコードを別のdllに再因子付けして参照を追加し、名前空間がMyproject.Modelsのままであれば、MVCアプリケーションは引き続き動作します。

データアクセスレイヤでも同じことができました。

私はMVCプロジェクトでアプリケーションを開発し、DALとビジネスレイヤーをフォルダ（ネームスペース）で分けることをお勧めします。アプリケーションが動作したら、必要に応じて再因子化することができます。

Answer 2

通常、物事を分けておくことをお勧めします。

これは、ビジネスロジックをデータベース管理コードと混在させず、ビューファイルにUI以外のコードを持つことを意味します。

これにより、作成したコードを他の人が理解しやすくなります。また、いくつかのプロジェクトに戻って、時間をかけて改善したり、エラーを訂正したりするとき、私はあなたを助けます。

もう一度撮影しないと、これがあなたの質問に答えることを願っています。

編集：これはMVCフレームワークでどのように行われているかを説明しているlinkです。

Answer 3

layered architectureを使用して、各レイヤーをSeparated Interfaceパターンで分離します。データベースの場合は、Repository pattern（最も簡単な方法は、nhibernateのようなORMを使用する）です。

inversion of control containerを使用すると、（インターフェイスの助けを借りて）結合を減らし、クラス間の依存関係を扱いやすくします。