我应该将实用程序类放在 ASP.NET MVC3 应用程序中的什么位置？
我正在使用 C# 和 Razor 在 ASP.NET MVC3 中开发 Web 应用程序。
我需要创建一个实用程序类，在其中放置将字符串转换为日期（年、月、日等）的函数。
在 ASP.NET Web 窗体中，我曾经将此类类放置在 App_Code 文件夹中。在 MVC 中没有这样的文件夹，我认为实用程序类既不属于模型也不属于Helpers（我创建的文件夹我在 HTML Helpers 上的扩展）。
我读到，将实用程序类放置在不同的程序集中是一个很好的做法。我想应该有一个不同的项目来完成这项工作，但是我应该创建什么样的项目呢？对我来说，简单的类库项目似乎是最合乎逻辑的选择。
然而，就我而言，我只需要放置一个具有多种方法的类，因此，如果我们忽略可重用性，那么将实用程序类放置在我的 MVC3 Web 应用程序中的某处不是更符合逻辑吗？
I am developing a web application in ASP.NET MVC3 with C# and Razor.
I need to create an utility class where I put functions to convert string into dates(years, months, days, etc...).
In ASP.NET Web Forms I used to place this kind of classes inside the App_Code folder. In MVC there is not such folder and I don't think utility classes belong neither to Models nor to Helpers(a folder I created to put my extensions on HTML Helpers).
I read that is a good practice to place the utility classes in a different assembly. I guess a different project should do the job but what kind of project shall I create? A plain Class Library project seem the most logical choice to me.
However in my case I just need to put one single class with several methods so, if we ignore re-usability, isn't it more logic to put the utility class somewhere in my MVC3 Web application?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你不应该有实用程序类。将它们转换为扩展方法会更好一些。视图模型甚至更好。
我通常为管道创建一个名为“HtmlHelpers”或“Infrastructure”的文件夹。
恕我直言，“通用”文件夹就像垃圾桶。你把所有的垃圾都放进去了。
更新
我会将其放置在 DateTime 的扩展方法中（放置在名为 DateTimeExtensions 的类中，该类放置在名为 Infrastructure 的命名空间中）。
我会在视图模型内部或生成视图模型（在控制器中）时使用它。
至于哪个项目，其实并不重要。重要的是您可以参加具有特定任务（或职责）的小班课程。
有些人认为应该有几个具有不同职责的类库。我不这样做。我创建了一个 UI 项目和一个业务逻辑项目。但是，我确保这些类实现一个或多个接口，以便稍后能够重构应用程序。 KISS 还应该适用于项目结构，而不仅仅是其中的代码。
换句话说：我会将我的助手放在名为“基础设施”的命名空间中的核心（业务逻辑项目）中。
You should not have utility classes. Convert them to extension methods which is somewhat better. View models are even better.
I usually create a folder called "HtmlHelpers" or "Infrastructure" for plumbing.
A "Common" folder is like the trashcan imho. You put all the junk in it.
Update
I would place it in an extension method for DateTime (placed in a class called DateTimeExtensions which is placed in a namespace called Infrastructure).
And I would use it internally in the view model or when generating the view model (in the controller).
As for which project, it doesn't really matter. What's important is that you got small classes with specific tasks (or responsibilities).
Some argue that you should have several class libraries with distinct responsibilities. I don't do that. I create one UI project and one project for the business logic. However, I make sure that the classes implement one or more interfaces to be able to refactor the application later on. KISS should also apply to project structure and not just the code in them.
In other words: I would put my helpers in the Core (business logic project) in a namespace called Infrastructure.
称之为 Common，把所有东西都放在那里。
然后使用像这些示例一样的命名空间
Common.Formatters
常用函数
通用.Foo
普通酒吧
Call it Common put everything in there.
Then use namespaces like these examples
Common.Formatters
Common.Functions
Common.Foo
Common.Bar
为什么不在项目中创建另一个名为“实用程序”、“基础设施”或类似的文件夹（例如在“助手”文件夹旁边）并将实用程序类放在那里。
一旦需要重用它，您始终可以将其移动到单独的 DLL（类库项目）中。
Why don't you create another folder named Utility, Infrastructure or similar in your project (next to the Helpers folder for example) and put the utility class(es) there.
You can always move it to a separate DLL (class library project) once you have a need to reuse it.
我更喜欢创建一个名为 Helpers 的文件夹和命名空间，如下所示：
我可以在 ASP.NET MVC 中的哪里放置自定义类？
I prefer creating a folder and namespace called Helpers as suggested here:
Where can I put custom classes in ASP.NET MVC?