14

我目前正在开发一个 ASP.net MVC 网站项目。

我已经将所有与数据库相关的东西都放在了我的模型中，例如查询和更新/删除/保存功能。

我还创建了几个执行逻辑的控制器。我添加了一个 Helpers 命名空间，在该命名空间内有一些包含分页、国际化等逻辑的类。

我想知道放置做一些一般事情的函数和类的最佳实践是什么，比如生成发票？

4

6 回答 6

5

正如我在上面的评论中所表达的，我对这个问题非常感兴趣。

首先，直接在 ASP.NET MVC 项目中创建附加目录（用于其他类和实用程序）似乎是错误的。另外，我觉得它不应该在模型中。对我来说，模型或多或少是数据类，它以某种方式代表数据库（或我们试图建模的数据）。最重要的是，业务功能（或应用程序中的“真实”代码段）通常一次处理多个模型类，因此在某些模型类中可能没有自然的位置。

所以我认为我倾向于以下模式：

  • 使控制器动作非常小；每个只有几行代码。
  • 保持模型简单且大部分无功能，并将其放入单独的项目中。
  • 将完成所有“真正”工作的所有代码（“业务层”）放入一个单独的项目中。

这样，您将在选择自己的命名空间时获得完全的自由，您将能够创建任意数量的实用程序类、函数，并且通常能够按照您的喜好构建您的代码，而不受 ASP.NET MVC 的限制。

这只是一个想法。目前我正在开发我的第一个更大的 ASP.NET MVC 应用程序。所以我实际上要了解这是否以及如何在实践中发挥作用。

于 2009-09-30T14:57:15.027 回答
1

我有像你一样有 Crud 和 Poco 的模型类。

除此之外，我还有用于类型化视图的视图模型。

我的 Viewmodel 非常大，并且在几个视图中使用（整个应用程序大约有 10-15 个视图模型）。在我的应用程序中，这些 ViewModel 最终成为了代码的完美位置，这些代码对控制器操作进行了大而重复的操作。

例如，当我将产品添加到购物车时，我有一些非常接近 UI 的逻辑。我现在在 ViewModel 中有一个方法：AddToCart(IProductService productService, ICartService cartService)。

于 2009-09-29T12:03:40.223 回答
0

您可能会考虑创建一些注入到控制器中的服务。

这几乎是一个太宽泛的问题。

于 2009-09-29T08:57:52.310 回答
0

这种业务逻辑应该在你的模型中。

但是，我发现当某些东西在任何地方都不真正“适合”时——并且你可能想创建一个实用程序类——这通常是使用扩展方法的好地方。

也许您可以在数据集上添加扩展方法来帮助您进行分页？

于 2009-09-29T08:58:33.417 回答
0

如果您真的需要最佳实践，请考虑查看Domain Driven Design。它并不适合所有项目，并且确实需要良好的 OOP 技能，但我认为这无疑是一种“最佳实践”……只要你能负担得起 ;-)

请注意，由于您使用 Active Record 模式（将持久性逻辑放入实体中），因此您已经违反了 DDD。所以，我并不是说你必须遵循 DDD。但无论如何，摸索会很有用。

于 2009-09-29T11:42:18.543 回答
0

我认为这个关于实践的问题的最佳解决方案是：如果要跨控制器使用逻辑，请将其放入模型中。如果它是特定于控制器的，只需将其放入您的控制器中。当我说模型时，它可能是包含实体数据模型的单独项目，也可能是视图模型，也可能只是 MVC 项目的模型文件夹。

于 2011-08-09T14:02:14.747 回答