MVC/MVP/MVVM - 如何组织业务逻辑

Question

这篇文章类似于in MVC/MVP/MVPC where do you put your business logic?，但我正在寻找更多细节。我已经将模型作为绝大多数业务逻辑应该驻留的地方。然而，据我所知，模型内部有很多东西：应用程序状态管理、数据持久性、存储库、数据传输对象，可能还有其他东西。

我有一个具有超级复杂业务规则的应用程序。当用户尝试在视图中执行某个特定操作时，大约有 20 条不同的规则必须验证是否应允许该操作，或者是否必须提示用户提供其他信息。我想为每个方法编写这些业务规则，以支持可测试性和文档。这些规则应该在存储库类中吗？也许在存储库上方的服务层中？请记住，我使用的是诸如 Linq to SQL、EF 或 nHibernate 之类的 ORM 解决方案，这里的最佳做法是什么？

Answer 1

首先，不要忘记在 MVP 中，您可以在视图中维护状态，因此模型中发生的事情就更少了。

存储库和服务层方法都可能适用。我想我很想使用几个测试应用程序同时探索两者。当你去的时候，你可能会觉得一个比另一个更合适，此时你可以专注于正确的方法。

这听起来像是白​​费力气，但与真正开始开发后转换方法所付出的努力相比要少得多。

Answer 2

了解 CSLA.NET 如何处理业务规则可能会很有趣： http://www.lhotka.net/cslanet/

Answer 3

如果它们是业务规则，我会将它们放在数据库表中，以便于更改。

代码本身就是业务规则愚蠢的，不关心规则的内容，只关心规则容器的结构。

关于您下面的 cmets，如果您出于其他原因需要将您的方法限制为以代码为中心的方法，那很好，但这只会使项目的开发成本显着增加。

规则越复杂，您就越能从表格驱动而不是硬编码中受益。如果您不习惯，困难的部分可能是为规则提出一个模型。模型建立后，开发就很简单了。