在哪里放置帮助我执行控制器任务的函数？
我目前正在开发一个 ASP.net MVC 网站项目。
我已将所有与数据库相关的内容放入模型中，例如查询和更新/删除/保存功能。
我还创建了几个执行逻辑的控制器。我添加了一个 Helpers 命名空间，在该命名空间内有一些包含分页、国际化等逻辑的类。
我想知道放置执行一些常规操作（例如生成发票）的函数和类的最佳实践是什么？
I'm currently working on an ASP.net MVC web site project.
I've put all database related stuff in my model, such as queries and update/delete/save functions.
I also created a couple of controllers that execute the logic. I added a Helpers namespace and inside that namespace there are a few classes that contain logic for pagination, internationalization etc.
I was wondering what is the best practice for placing functions and classes that do some general stuff, like generating an invoice?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这种业务逻辑应该位于模型中的某个位置。
然而，我发现当有些东西并不真正“适合”任何地方时 - 并且您可能会想创建一个实用程序类 - 这通常是利用扩展方法的好地方。
也许您可以在数据集上添加扩展方法来帮助您进行分页？
This kind of business logic should be somewhere in your Model.
However, I find that when there is just something that doesn't really "fit" anywhere - and you might be tempted to create a Utilities class - this is usually a good place to utilize Extension methods.
Perhaps you can add extension methods on your dataset to help you with pagination?
如果您确实需要最佳实践，请考虑查看领域驱动设计< /a>.它并不适合所有项目，并且确实需要良好的 OOP 技能，但我认为这无疑是一种“最佳实践”...只要您负担得起；-)
请注意，由于您使用 Active，您已经违反了 DDD记录模式（将持久性逻辑放入实体中）。因此，我并不是说您必须遵循 DDD。但无论如何，摸索一下还是很有用的。
I you really need the best practice, consider looking at Domain Driven Design. It doesn't suit all projects and does require good OOP skills, but I think it is without doubts a "best practice"... as long as you can afford it ;-)
Notice that you do already violate DDD since you use Active Record pattern (put persistence logic into entities). So, I do not say that you have to follow DDD. But it will be useful to grok anyway.
我认为解决这个关于实践的问题的最佳答案是：
如果要跨控制器使用逻辑，请将逻辑放入模型中。
如果它是特定于控制器的，只需将其放入控制器中即可。
当我说模型时，这可能是一个包含实体数据模型的单独项目，也可能是视图模型，也可能只是 MVC 项目的模型文件夹。
I think the best solution to this question about practice is:
Put the logic in the Model if it's going to be used across controllers.
If it's controller specific, just drop it in your controller.
When I say the Model, this could be a separate project that conatins your Entity Data Model, or it could be a View Model, or it could be just the Models folder of your MVC project.
正如我在上面的评论中所表达的，我对这个问题非常感兴趣。
首先，直接在 ASP.NET MVC 项目中创建附加目录（用于其他类和实用程序）似乎是错误的。另外，我不认为它应该在模型中。对我来说，模型或多或少是数据类，它以某种方式代表数据库（或我们尝试建模的数据）。最重要的是，业务功能（或应用程序中的“真实”代码段）通常一次处理多个模型类，因此在某些模型类中可能没有合适的位置。
所以我认为我倾向于以下模式：
这样，您将完全自由地选择自己的命名空间，您将能够创建任意数量的实用程序类、函数，并且通常能够根据您的喜好构建代码，而不受 ASP.NET MVC 的限制。
这只是一个想法。目前我正在开发我的第一个大型 ASP.NET MVC 应用程序。所以我实际上要了解这在实践中是否有效以及如何运作。
As I expressed in a comment above, I’m too very much interested in this question.
First, it seems wrong to create additional directories (for the other classes and utilities) directly in your ASP.NET MVC project. Also, I don’t feel that it should be in model. To me, model is more or less data classes which in some way represents the database (or the data we are trying to model). On top of that, often the business functionality (or the "real" pieces of code in your application) deals with several model classes at a time, and so there may not be a natural place for it in some model class.
So I think I am leaning towards the following schema:
This way you will get a complete freedom in choosing your own namespaces, you will be able to create any number of utility classes, functions, and generally able to structure your code as you like without being restricted by ASP.NET MVC.
This is just an idea. At the moment I’m working on my first larger ASP.NET MVC application. So I’m actually going to learn whether and how this works in practice.
我有像你一样有 Crud 和 Poco 的 Model 类。
除此之外，我还有用于类型化视图的视图模型。
我的视图模型非常大，并且在几个视图中使用（整个应用程序大约有 10-15 个视图模型）。在我的应用程序中，这些 ViewModel 最终成为了代码的完美位置，这些代码对于控制器操作来说是大而重复的。
例如，当我将产品添加到购物车时，我有一些非常接近 UI 的逻辑。我现在在 ViewModel 中有一个方法：AddToCart(IProductService ProductService, ICartService cartService)。
I have Model classes that have Crud and Poco like you have.
Apart from that I have Viewmodels that are used for the typed Views.
My Viewmodels are pretty big and used in a couple of views (around 10-15 viewmodels for the whole appplication). In my application these ViewModels ended up as being the perfect place for the code that seamed to big and repetetive for the controller actions.
For example I have some logic that is pretty near to UI when I add a Product to the Cart. I now have a method in the ViewModel: AddToCart(IProductService productService, ICartService cartService).
您可能会考虑创建一些注入控制器的服务。
这个问题几乎太宽泛了。
You might consider creating some services that you inject into your controllers.
It's almost too wide a question.