我应该如何实现我的业务逻辑层?
Posted
技术标签:
【中文标题】我应该如何实现我的业务逻辑层?【英文标题】: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 部分和应用程序其余部分的模式,或者我应该为应用程序的不同部分使用不同的模式?
【问题讨论】:
【参考方案1】:我强烈建议您阅读behavior-driven development。我认为它会引导你朝着正确的方向前进。
我读过的关于这个主题的最好的书是The RSpec Book,但如果你对很多以 Ruby 为中心的例子感到厌烦,你可能想看看基于你最喜欢的语言的其他资源。
简而言之,您的问题的答案是:让您的测试指导您的架构,让您的应用所需的行为指导您的测试。
【讨论】:
【参考方案2】:我不认为 CRUD 是业务规则。
我不确定是否存在这样的规则模式,例如“为首选客户提供百分比折扣,该折扣是他们今年迄今为止的销售量的函数”或“不要在用户界面中为以下客户显示此选项”公司地址来自此州列表”。
业务规则并不总是那么整洁。
【讨论】:
好吧,大多数时候我都有 CRUD 规则,比如“插入 foo 时,也插入一个带有 foo id 的栏”这样的规则可以直接在 db 上实现,但 db 管理员不太喜欢那个。 类似的东西属于知道用例的服务层,而不是持久层本身。 CRUD 操作应该只封装如何持久化对象的机制,而不是什么时候做。以上是关于我应该如何实现我的业务逻辑层?的主要内容,如果未能解决你的问题,请参考以下文章