我从未遇到过写得很好的业务层.有什么建议吗? [英] I've never encountered a well written business layer. Any advice?

问题描述

我环顾四周，看到了一些很棒的代码片段，用于定义规则，验证，业务对象(实体)等，但是我不得不承认从未见过完整的出色且编写良好的业务层. /p>

我只知道自己不喜欢什么，却不知道自己是多么棒.

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

谢谢

解决方案

经过全面的域分析，设计出了良好的业务层.如果您可以捕获业务的语义并将其与任何类型的实现(无论是在数据存储中还是在任何特定的应用程序(包括表示形式)中)隔离开，那么该逻辑应具有良好的结构并可在不同的上下文中重用.

就像一个好的数据库架构设计应该捕获业务语义并将自身与任何应用程序隔离一样，业务层也应该做到这一点，即使数据库架构和业务层描述了相同的实体和概念，两者也应该是可用的在单独的上下文中-除非业务逻辑发生更改，否则数据库架构也不必更改，除非该架构不能反映当前业务.如果通过中间层将业务层抽象化，那么业务层应该可以与任何存储方案一起使用.例如，ADO.NET实体框架使您可以设计一个 conceptual 架构，该架构映射到业务层，并具有一个单独的映射到存储架构的映射，可以更改该映射而无需重新编译业务对象层或概念层

如果业务方面的人员可以查看用业务层编写的代码并大致了解正在发生的事情，那么这可能很好地表明了对象的设计正确—您已经成功传达了问题域中的解决方案，而不会与解决方案域中的工件混淆.

I look around and see some great snippets of code for defining rules, validation, business objects (entities) and the like, but I have to admit to having never seen a great and well-written business layer in its entirety.

I'm left knowing what I don't like, but not knowing what a great one is.

Can anyone point out some good OO business layers (or great business objects) or let me know how they judge a business layer and what makes one great?

Thanks

解决方案

Good business layers have been designed after a thorough domain analysis. If you can capture the business' semantics and isolate it from any kind of implementation, whether that be in data storage or any specific application (including presentation), then the logic should be well-factored and reusable in different contexts.

Just as a good database schema design should capture business semantics and isolate itself from any application, a business layer should do the same and even if a database schema and a business layer describe the same entities and concepts, the two should be usable in separate contexts--a database schema shouldn't have to change even when the business logic changes unless the schema doesn't reflect the current business. A business layer should work with any storage schema provided that it's abstracted via an intermdiate layer. For example, the ADO.NET Entity framework lets you design a conceptual schema which maps to the business layer and has a separate mapping to the storage schema which can be changed without recompiling the business object layer or conceptual layer.

If a person from the business side of things can look at code written with the business layer and have a rough idea of what's going on then it might be a good indication that the objects were designed right--you've succesfully conveyed a solution in the problem domain without obfuscating it with artifacts from the solution domain.

这篇关于我从未遇到过写得很好的业务层.有什么建议吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！