我对尝试确定将应用程序的业务规则放在何处感到困惑。
我正在使用asp.net传统的Web表单（而不是mvc）开发一个Web应用程序，最重要的是我有一个类库，其中我有用于写入数据库的存储库模式。我在存储库模式中有一个“业务层”，而且，我正在编写存储过程以影响表。
我应该在哪里提出强制性字段验证规则？
其他例子是，将外币兑换成美元（我有一个汇率表，目前我在sprocs中这样做）。
您是否建议远离sprocs获取规则并在我的存储库业务层中构建所有内容？或者您在什么情况下建议在sprocs中构建规则和验证？
答案 0 :(得分：4)
如果您开发的小应用程序不使用多个数据源，或者没有经过大量单元测试的业务层，并且您不打算添加服务层（例如用于缓存），那么这个答案是合适的）。请参阅评论中的反对意见。
如果可以，我可以建议：
将业务逻辑保留在业务层中，而不是数据库中。好处在于规则的地方。您的所有域名都表示为一组条件，规则，策略等。它们都位于一个地方。如果您选择将它们存储在数据库中，则在维护代码时会给自己带来额外的麻烦。
单位测试业务层中的代码很容易。我不确定是否可以对SP进行单元测试。
SP和存储库模式不能很好地结合在一起。
货币汇率每时每刻变化，为此你应该使用一个可靠的网络服务，你可以调用并获得一个精确的价值。
<强>要点：
答案 1 :(得分：1)
您的存储库不应该有业务层。它的唯一目的应该是充当数据库的抽象。在其中，您可以管理存储/检索应用程序数据的方式。
将SP用于不经常更改的数据库操作。切勿将您的业务逻辑放在SP中。业务逻辑有随时间变化的趋势。
您可以创建业务对象所在的域层。您的业务对象应该封装自己的验证逻辑。
除了您的业务/域对象之外，您可能还有实用程序类（例如CurrencyManager或CurrencyHelper），它们实际上使用您的业务对象来根据数据验证业务逻辑。
最后尝试让您的域免受任何类型的演示文稿/视图图层引用。不要在视图层应用业务验证规则或在域层显示验证逻辑。
- 希望能够解释一下。