3

试图确定将业务规则放置在我的应用程序的位置时，我有点困惑。

我正在使用 asp.net 常规 Web 表单（不是 mvc）开发一个 Web 应用程序，最重要的是我有一个类库，其中我有用于写入数据库的存储库模式。我在存储库模式中有一个“业务层”，而且我正在编写存储过程来影响表。

例如，我应该在哪里放置强制字段验证规则？

其他示例是将外币转换为美元（我有一个汇率表，目前我在 sprocs 中进行）。

您是否建议远离存储库的规则并在我的存储库业务层中构建所有内容？或者在什么情况下，您建议在 sprocs 中构建规则和验证？

4

2 回答 2

4

如果您开发的小型应用程序不使用多个数据源或没有经过广泛单元测试的业务层，并且您不打算添加服务层（例如用于缓存），则此答案是合适的。请参阅评论中的反对意见。

如果可以，我可以建议：

  1. 完全删除存储库模式。你真的需要支持多个数据库吗？

  2. 将业务逻辑保存在业务层中，而不是数据库中。好处在于规则的本地化。您的所有域都表示为一组条件、规则、策略等。它们都位于一个地方。如果您选择将它们存储在数据库中，那么在维护代码时会给自己带来额外的麻烦。

  3. 对业务层中的代码进行单元测试很容易。我不确定是否可以对 SP 进行单元测试。

  4. SP 和存储库模式不能很好地结合在一起。

货币汇率每分每秒都会发生变化，为此您应该使用可靠的 Web 服务，您可以调用该服务并获得精确的值。

概括：

  • 远离SP
  • 远离存储库模式
  • 直接使用 ORM 而不是存储库模式抽象
  • 不要混合持久性和业务规则
  • 在单独的（可重用）程序集中分离您的业务规则
于 2012-07-23T23:39:19.027 回答
1

  • 您的存储库不应该有业务层。它的唯一目的应该是充当数据库的抽象。在其中，您可以管理存储/检索应用程序数据的方式。

  • 将 SP 用于不经常更改的数据库操作。永远不要将您的业务逻辑放在 SP 中。业务逻辑有随时间变化的趋势。

  • 您可以创建业务对象所在的域层。您的业​​务对象应该封装自己的验证逻辑。

  • 除了您的业务/域对象之外，您可能还有实用程序类（例如 CurrencyManager 或 CurrencyHelper），它们实际上使用您的业务对象来根据数据验证业务逻辑。

  • 最后尝试使您的域免受任何形式的表示/视图层参考。不要在视图层应用业务验证规则或在域层显示验证逻辑。

-希望这会有所启发。

于 2012-07-24T04:04:56.600 回答