現在、ASP.net MVC Web サイト プロジェクトに取り組んでいます。
クエリや更新/削除/保存機能など、すべてのデータベース関連のものをモデルに入れました。
また、ロジックを実行するコントローラーもいくつか作成しました。Helpers 名前空間を追加しました。その名前空間内には、ページネーション、国際化などのロジックを含むクラスがいくつかあります。
請求書の生成など、一般的なことを行う関数やクラスを配置するためのベストプラクティスは何ですか?
現在、ASP.net MVC Web サイト プロジェクトに取り組んでいます。
クエリや更新/削除/保存機能など、すべてのデータベース関連のものをモデルに入れました。
また、ロジックを実行するコントローラーもいくつか作成しました。Helpers 名前空間を追加しました。その名前空間内には、ページネーション、国際化などのロジックを含むクラスがいくつかあります。
請求書の生成など、一般的なことを行う関数やクラスを配置するためのベストプラクティスは何ですか?
上記のコメントで述べたように、私はこの質問に非常に興味があります。
まず、ASP.NET MVC プロジェクトに追加のディレクトリ (他のクラスやユーティリティ用) を直接作成するのは間違っているようです。また、モデルにすべきだとは思いません。私にとって、モデルは多かれ少なかれデータベース (またはモデル化しようとしているデータ) を何らかの形で表すデータ クラスです。その上、多くの場合、ビジネス機能 (またはアプリケーション内の「実際の」コード) は、一度に複数のモデル クラスを処理するため、一部のモデル クラスにそのための自然な場所がない場合があります。
したがって、次のスキーマに傾いていると思います。
このようにして、独自の名前空間を完全に自由に選択できるようになり、任意の数のユーティリティ クラス、関数を作成でき、一般に、ASP.NET MVC によって制限されることなく、好きなようにコードを構造化できます。
これは単なるアイデアです。現在、私は最初の大規模な ASP.NET MVC アプリケーションに取り組んでいます。ですから、これが実際にどのように機能するかを実際に学びます。
私はあなたのような Crud と Poco を持つ Model クラスを持っています。
それとは別に、型付きビューに使用されるビューモデルがあります。
私のビューモデルはかなり大きく、いくつかのビューで使用されています (アプリケーション全体で約 10 ~ 15 個のビューモデル)。私のアプリケーションでは、これらの ViewModels は、コントローラ アクションのために大きくて反復的なコードを配置するのに最適な場所になりました。
たとえば、製品をカートに追加するときの UI にかなり近いロジックがいくつかあります。ViewModel に AddToCart(IProductService productService, ICartService cartService) というメソッドがあります。
ベストプラクティスが本当に必要な場合は、 Domain Driven Designを検討してください。すべてのプロジェクトに適しているわけではなく、優れた OOP スキルが必要ですが、余裕がある限り、間違いなく「ベスト プラクティス」だと思います ;-)
Active Record パターンを使用しているため (永続化ロジックをエンティティに挿入)、既に DDD に違反していることに注意してください。ですから、 DDD に従わなければならないとは言いません。しかし、とにかく grok することは役に立ちます。
コントローラーに注入するいくつかのサービスを作成することを検討してください。
それはほとんど広すぎる質問です。
この種のビジネス ロジックは、モデルのどこかにある必要があります。
ただし、実際にはどこにも「収まらない」ものがあり、Utilities クラスを作成したくなる場合は、通常、これが拡張メソッドを利用するのに適した場所であることがわかりました。
おそらく、データセットに拡張メソッドを追加して、ページネーションを支援することができますか?
実践に関するこの質問に対する最良の解決策は、次のとおりだと思います。コントローラー間で使用する場合は、ロジックをモデルに配置します。コントローラー固有の場合は、コントローラーにドロップするだけです。モデルと言うとき、これはエンティティ データ モデルを含む別のプロジェクト、ビュー モデル、または MVC プロジェクトのモデル フォルダーのいずれかです。