C# と Razor を使用して ASP.NET MVC3 で Web アプリケーションを開発しています。
文字列を日付 (年、月、日など) に変換する関数を配置するユーティリティ クラスを作成する必要があります。
ASP.NET Web フォームでは、この種のクラスをApp_Codeフォルダー内に配置していました。MVC にはそのようなフォルダーはなく、ユーティリティ クラスはモデルにもヘルパー(拡張機能を HTML ヘルパーに配置するために作成したフォルダー) にも属していないと思います。
ユーティリティ クラスを別のアセンブリに配置することをお勧めします。別のプロジェクトで作業を行うべきだと思いますが、どのようなプロジェクトを作成すればよいでしょうか? 単純なクラス ライブラリ プロジェクトは、私にとって最も論理的な選択のように思えます。
ただし、私の場合、複数のメソッドを持つ 1 つのクラスを配置するだけでよいので、再利用性を無視すると、MVC3 Web アプリケーションのどこかにユーティリティ クラスを配置するほうが理にかなっているのではないでしょうか?
ユーティリティクラスは必要ありません。それらを拡張メソッドに変換します。これはやや優れています。ビューモデルはさらに優れています。
私は通常、配管用に「HtmlHelpers」または「Infrastructure」というフォルダーを作成します。
「共通」フォルダは、ゴミ箱の私見のようなものです。あなたはそれにすべてのがらくたを入れます。
これをDateTimeの拡張メソッドに配置します（Infrastructureという名前空間に配置されたDateTimeExtensionsというクラスに配置されます）。
そして、ビューモデルの内部で、またはビューモデルを生成するときに（コントローラーで）使用します。
どのプロジェクトかは関係ありません。重要なのは、特定のタスク（または責任）を持つ少人数のクラスを受講することです。
明確な責任を持ついくつかのクラスライブラリが必要であると主張する人もいます。私はそれをしません。ビジネスロジック用に1つのUIプロジェクトと1つのプロジェクトを作成します。ただし、後でアプリケーションをリファクタリングできるように、クラスが1つ以上のインターフェイスを実装していることを確認します。KISSは、プロジェクト構造だけでなく、プロジェクト構造にも適用する必要があります。
言い換えると、インフラストラクチャと呼ばれる名前空間のコア（ビジネスロジックプロジェクト）にヘルパーを配置します。
それをコモンと呼び、そこにすべてを入れます。
次に、これらの例のような名前空間を使用します
Common.Formatters Common.Functions Common.Foo Common.Bar
プロジェクトに Utility、Infrastructure などの名前の別のフォルダー (たとえば、Helpers フォルダーの隣) を作成し、そこにユーティリティ クラスを配置してみませんか。
再利用する必要がある場合は、いつでも別の DLL (クラス ライブラリ プロジェクト) に移動できます。