这篇文章与in MVC/MVP/MVPC where do you put your business logic?类似，但我正在寻找更多细节。我已经购买了模型作为绝大多数业务逻辑应该驻留的地方。但是，据我所知，模型内部有很多内容：应用程序状态管理，数据持久性，存储库，数据传输对象以及其他可能的东西。
我的应用程序具有超级复杂的业务规则。当用户尝试在视图中执行某个特定操作时，大约有20个不同的规则必须验证是否应该允许该操作，或者是否必须提示用户提供其他信息。我想按照每个方法编写这些业务规则，以便支持可测试性和文档。这些规则应该在存储库类中吗？也许在存储库上方的服务层？这里最好的做法是记住我正在使用像Linq到SQL，EF或nHibernate这样的ORM解决方案吗？
答案 0 :(得分：1)
首先，不要忘记在MVP中，你有能力在视图中维护状态，这样在模型中发生的事情就少了。
存储库和服务层方法都可能适用。我想我很想尝试使用几个测试应用程序并行探索。当你走的时候，你可能会感觉到一个比另一个更合适，那时你可以专注于正确的方法。
这可能听起来像是浪费了精力，但一旦开发真正开始，它将远远低于切换方法的努力。
答案 1 :(得分：1)
了解CSLA.NET如何处理业务规则可能很有趣： http://www.lhotka.net/cslanet/
答案 2 :(得分：-2)
如果它们是业务规则，我会将它们放在数据库表中，以便它们易于更改。
代码本身就是业务规则愚蠢，并不关心规则的内容，只关心规则容器的结构。
关于下面的评论，如果由于其他原因需要限制以代码为中心的方法，那很好，这只会使开发项目的成本显着提高。
规则越复杂，您从表驱动而不是硬编码中受益的越多。如果您不习惯，那么困难的部分可能会为规则提出一个模型。在模型构建之后，开发很简单。