我从来没有遇到过写得好的业务层.有什么建议？

我环顾四周,看到一些很好的代码片段,用于定义规则,验证,业务对象(实体)等,但我不得不承认从未见过一个完整的,写得很好的业务层.

我知道我不喜欢什么,但不知道什么是伟大的.

任何人都可以指出一些优秀的OO业务层(或伟大的业务对象)或让我知道他们如何判断业务层以及什么使一个伟大的？

谢谢

我从来没有遇到过写得好的业务层.

这是Alex Papadimoulis对此的看法:

[...]如果您考虑一下,软件应用程序中几乎每行代码都是业务逻辑:

Customers数据库表,其CustomerNumber(CHAR-13),ApprovedDate(DATETIME)和SalesRepName(VARCHAR-35)列:业务逻辑.如果不是,它只是Table032与Column01,Column02和Column03.

向第一次客户提供10%折扣的子程序:绝对是业务逻辑.并且希望不是软编码的.

以红色突出显示过期发票的代码:这也是业务逻辑.Internet Explorer当然不会寻找"无偿"和"30天以上"的字符串,嘿,这肯定会在#990000背景下看起来很棒!

那么如何将所有这些业务逻辑封装在单层代码中呢？有可怕的架构和糟糕的代码当然!

[...]通过暗示系统的体系结构应该包含专用于业务逻辑的层,许多开发人员使用各种非常聪明的技术来实现该目标.它总是在灾难中结束.

我想这是因为商业逻辑作为一般规则是任意和令人讨厌的.垃圾进垃圾出.

此外,大多数非常好的业务层很可能是专有的.;-)

经过彻底的域分析后,设计了良好的业务层.如果您可以捕获业务的语义并将其与任何类型的实现隔离,无论是在数据存储还是任何特定应用程序(包括表示)中,那么逻辑应该在不同的上下文中得到充分考虑和重用.

正如一个好的数据库模式设计应该捕获业务语义并将自己与任何应用程序隔离开来一样,业务层也应该这样做,即使数据库模式和业务层描述相同的实体和概念,这两个应该可以在不同的上下文中使用 - 即使业务逻辑发生更改,数据库模式也不必更改,除非模式不反映当前业务.业务层应该与任何存储架构一起使用,前提是它通过中间层抽象.例如,ADO.NET Entity框架允许您设计概念映射到业务层架构,并具有到存储架构的单独映射,无需重新编译业务对象层或概念层即可对其进行更改.

如果业务方面的人员可以查看使用业务层编写的代码,并且大致了解正在发生的事情,则可能是对象设计正确的良好迹象 - 您已成功传达了解决方案问题域没有使用解决方案域中的工件来混淆它.