我应该如何实现我的业务逻辑层？答案

【问题标题】：How should i implement my Business Logic Layer?我应该如何实现我的业务逻辑层？
【发布时间】：2011-06-01 08:48:23
【问题描述】：

假设我的应用程序具有 80% 的复杂业务逻辑和 20% 的 CRUD，反之亦然。

过去我使用过某种命令模式，并有类似ComplexFooCMD 或EvenMoreComplexBarCMD 这样的类，但总是以一堆InsertFoo、UpdateFoo、DeleteFoo 和SelectFoosCMD 结尾少数UpdateSomeValuesOfFoo 或SelectSomeFoos。所有这些都生活在 BLL 中。

最近在不太复杂的业务逻辑应用程序中，我使用了带有类的服务模式，例如FooService，但这些也包含预期的insertFoo、updateFoo 和selectSomeFoo。在每个服务上都使用这些方法，甚至拥有仅用于将这些方法公开给表示层的服务，感觉就像是大量的样板代码。

是否有适合 CRUD 部分和应用程序其余部分的模式，或者我应该为应用程序的不同部分使用不同的模式？

【问题讨论】：

标签： architecture bll

【解决方案1】：

我强烈建议您阅读behavior-driven development。我认为它会引导你朝着正确的方向前进。

我读过的关于这个主题的最好的书是The RSpec Book，但如果你对很多以 Ruby 为中心的例子感到厌烦，你可能想看看基于你最喜欢的语言的其他资源。

简而言之，您的问题的答案是：让您的测试指导您的架构，让您的应用所需的行为指导您的测试。

【讨论】：

【解决方案2】：

我不认为 CRUD 是业务规则。

我不确定是否存在这样的规则模式，例如“为首选客户提供百分比折扣，该折扣是他们今年迄今为止的销售量的函数”或“不要在用户界面中为以下客户显示此选项”公司地址来自此州列表”。

业务规则并不总是那么整洁。

【讨论】：

好吧，大多数时候我都有 CRUD 规则，比如“插入 foo 时，也插入一个带有 foo id 的栏”这样的规则可以直接在 db 上实现，但 db 管理员不太喜欢那个。
类似的东西属于知道用例的服务层，而不是持久层本身。 CRUD 操作应该只封装如何持久化对象的机制，而不是什么时候做。