我正在用C#和Razor在ASP.NET MVC3中开发一个web应用程序。
我需要创建一个实用程序类，在其中我放置了将字符串转换为日期（年、月、天等）的函数。
在ASP.NET Web窗体中，我曾将此类类放在App_Code文件夹中。在MVC中没有这样的文件夹，我认为实用程序类既不属于模型，也不属于帮助程序（我创建的一个文件夹，用于将扩展放在HTML帮助程序上）。
我读到将实用程序类放置在不同的程序集中是一种很好的做法。我想应该用另一个项目来完成这项工作，但我应该创建什么样的项目？一个简单的类库项目对我来说似乎是最合乎逻辑的选择。
然而，在我的情况下，我只需要把一个类和几个方法放在一起，所以，如果我们忽略可重用性，把实用程序类放在我的MVC3 Web应用程序中的某个地方不是更合乎逻辑吗？
您不应该有实用程序类。将它们转换为更好的扩展方法。视图模型甚至更好。
我通常为管道创建一个名为"HtmlHelpers"或"Infrastructure"的文件夹。
"通用"文件夹就像垃圾桶imho。你把所有的垃圾都放进去了。
更新
我会把它放在DateTime的一个扩展方法中（放在一个名为DateTimeExtensions的类中，该类放在名为Infrastructure的命名空间中）。
我会在视图模型内部使用它，或者在生成视图模型时（在控制器中）使用它。
至于哪个项目，其实并不重要。重要的是，你有一些特定任务（或职责）的小课堂。
有些人认为应该有几个具有不同职责的类库。我不这么做。我为业务逻辑创建了一个UI项目和一个项目。然而，我确保类实现一个或多个接口，以便以后能够重构应用程序。KISS也应该应用于项目结构，而不仅仅是其中的代码。
换句话说：我会把我的助手放在名为Infrastructure的命名空间中的Core（业务逻辑项目）中。
称之为Common，把所有东西都放在那里。
然后使用类似以下示例的名称空间
Common.FormatersCommon.函数Common.FooCommon.Bar
为什么不在项目中创建另一个名为Utility、Infrastructure或类似的文件夹（例如，在Helpers文件夹旁边），并将实用程序类放在那里。
一旦你需要重用它，你总是可以把它移到一个单独的DLL（类库项目）中
我更喜欢创建一个名为Helpers的文件夹和命名空间，如下所示：在ASP.NET MVC中，我可以将自定义类放在哪里？