如何设计业务逻辑层
明确地说，我不期望这个问题得到解决。解决这个问题的一个重要部分显然是解决问题。然而，我对架构良好的 n 层应用程序没有太多经验，而且我不想最终得到一个不守规矩的 BLL。
在撰写本文时，我们的业务逻辑很大程度上是一个混合的麻线球。星际间的依赖关系混乱不堪，且相同的业务逻辑被多次复制。我现在的重点是将业务逻辑从我们称为数据访问层的事物中拉出来，以便我可以定义可以订阅的众所周知的事件。我想我想支持事件驱动/反应式编程模型。
我希望有一些可实现的目标，告诉我如何以非常适合业务逻辑的方式设计这些类集合。如果有什么东西可以区分好 BLL 和坏 BLL，我想听到更多关于它们的信息。
作为一名经验丰富的程序员但相当谦虚的架构师，我向社区成员寻求建议。
编辑 1：
因此验证逻辑进入业务对象，但这意味着业务对象需要将验证错误/逻辑传达回 GUI。这让我开始考虑将业务操作实现为对象，而不是提供更多有关操作必要性的元数据的对象。我不太热衷于代码克隆。
To be perfectly clear, I do not expect a solution to this problem. A big part of figuring this out is obviously solving the problem. However, I don't have a lot of experience with well architected n-tier applications and I don't want to end up with an unruly BLL.
At the moment of writing this, our business logic is largely a intermingled ball of twine. An intergalactic mess of dependencies with the same identical business logic being replicated more than once. My focus right now is to pull the business logic out of the thing we refer to as a data access layer, so that I can define well known events that can be subscribed to. I think I want to support an event driven/reactive programming model.
My hope is that there's certain attainable goals that tell me how to design these collection of classes in a manner well suited for business logic. If there are things that differentiate a good BLL from a bad BLL I'd like to hear more about them.
As a seasoned programmer but fairly modest architect I ask my fellow community members for advice.
Edit 1:
So the validation logic goes into the business objects, but that means that the business objects need to communicate validation error/logic back to the GUI. That get's me thinking of implementing business operations as objects rather than objects to provide a lot more metadata about the necessities of an operation. I'm not a big fan of code cloning.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这是一个广泛的问题。使用 ORM 技术（也许是 NHibernate？）将您的数据库与业务逻辑（可怕的术语）分开。这让你（显然）大部分时间都停留在面向对象的领域，并且从架构的角度来看，你基本上可以忽略数据库方面的事情。
接下来，我发现领域驱动设计（DDD）是将复杂系统分解为可管理系统的最成功方法虽然它没有得到尊重，但我确实发现 UML（尤其是动作图和类图）对于理解和传达系统设计非常有用。
一般建议：连接所有内容，从一开始就构建单元测试，并学习识别和分离可以作为子系统存在的可重用服务组件。 FWIW，如果你们中有很多人在研究这个问题，我也会同意并从一开始就积极使用 stylecop :)
Kind of a broad question. Separate your DB from your business logic (horrible term) with ORM tech (NHibernate perhaps?). That let's you stay in OO land mostly (obviously) and you can mostly ignore the DB side of things from an architectural point of view.
Moving on, I find Domain Driven Design (DDD) to be the most successful method for breaking a complex system into manageable chunks, and although it gets no respect I genuinely find UML - especially action and class diagrams - to be critically useful in understanding and communicating system design.
General advice: Interface everything, build your unit tests from the start, and learn to recognise and separate the reusable service components that can exist as subsystems. FWIW if there's a bunch of you working on this I'd also agree on and aggressively use stylecop from the get go :)
我发现领域驱动设计的一些实践在将复杂的业务逻辑分解为更易于管理/可测试的块方面非常出色。
从以下链接查看示例代码：
http://dddpds.codeplex.com/
DDD 重点如果您愿意的话，可以在您的域层或 BLL 上进行操作，我希望它有所帮助。
I have found some o fthe practices of Domain Driven Design to be excellent when it comes to splitting up complex business logic into more managable/testable chunks.
Have a look through the sample code from the following link:
http://dddpds.codeplex.com/
DDD focuses on your Domain layer or BLL if you like, I hope it helps.
我们只是从架构的角度来谈论这个，剩下的要点就是“抽象、抽象、抽象”。
您可以使用 EBC 自顶向下设计并将接口定义传递给程序员团队。使用这样的方法（或任何其他可视化技术）可视化依赖关系可以防止您在项目中的任何地方重复业务逻辑。
We're just talking about this from an architecture standpoint, and what remains as the gist of it is "abstraction, abstraction, abstraction".
You could use EBC to design top-down and pass the interface definitions to the programmer teams. Using a methology like this (or any other visualisation technique) visualizing the dependencies prevents you from duplicating business logic anywhere in your project.
嗯，我可以告诉您我们用于相当大的以数据库为中心的应用程序的技术。我们有一个类按照您的建议管理数据层，其后缀为 DL。我们有一个程序可以自动生成这个源文件（这非常方便），但这也意味着如果我们想要扩展功能，您需要派生该类，因为在重新生成源文件时您将覆盖它。
我们有另一个以 OBJ 结尾的文件，它简单地定义了数据层处理的实际数据库行。
最后但并非最不重要的一点是，对于格式良好的基类，有一个以 BS（代表业务逻辑）结尾的文件，作为唯一未自动生成的文件，定义“新建”和“保存”等事件方法，以便通过调用基地，默认操作已完成。因此，任何与规范的偏差都可以在此文件中处理（包括在必要时完全重写默认功能）。
您应该为每个表及其派生自该主表的子（或孙）表创建一组此类文件。您还需要一个包含所有对象的全名的工厂，以便可以通过反射创建任何对象。因此，要修补程序，您只需从基本功能派生并更新数据库中的一行，以便工厂创建该对象而不是默认对象。
希望这会有所帮助，尽管我会将其保留为社区 wiki 响应，以便您也许可以获得有关此建议的更多反馈。
Hmm, I can tell you the technique we used for a rather large database-centered application. We had one class which managed the datalayer as you suggested which had suffix DL. We had a program which automatically generated this source file (which was quite convenient), though it also meant if we wanted to extend functionality, you needed to derive the class since upon regeneration of the source you'd overwrite it.
We had another file end with OBJ which simply defined the actual database row handled by the datalayer.
And last but not least, with a well-formed base class there was a file ending in BS (standing for business logic) as the only file not generated automatically defining event methods such as "New" and "Save" such that by calling the base, the default action was done. Therefore, any deviation from the norm could be handled in this file (including complete rewrites of default functionality if necessary).
You should create a single group of such files for each table and its children (or grandchildren) tables which derive from that master table. You'll also need a factory which contains the full names of all objects so that any object can be created via reflection. So to patch the program, you'd merely have to derive from the base functionality and update a line in the database so that the factory creates that object rather than the default.
Hope that helps, though I'll leave this a community wiki response so perhaps you can get some more feedback on this suggestion.
看看这个线程。可以给你一些想法。
我的业务逻辑应如何与我的业务逻辑交互数据层？
这个Microsoft 的指南也可能有帮助。
Have a look in this thread. May give you some thoughts.
How should my business logic interact with my data layer?
This guide from Microsoft could also be helpful.
关于“编辑1” - 我已经多次遇到过这个问题。我完全同意你的观点：有多个地方必须进行相同的验证。
我过去解决这个问题的方法是以某种方式封装验证规则。元数据/XML、单独的对象等等。只需确保它可以从业务对象请求、在其他地方获取并在那里执行即可。这样，您只需编写一次验证代码，它就可以由您的业务对象或 UI 对象执行，甚至可能由代码的第三方使用者执行。
有一个警告：一些验证规则很容易封装/传输；例如，“姓氏是必填字段”。但是，您的某些验证规则可能过于复杂，并且涉及太多对象，无法在元数据中轻松封装或描述：“只有当用户不是员工并且订单是在劳动节周末下的时，才可以包含该优惠券，并且他们的购物车中有 2 到 5 件这种特定类型的商品，除非他们的购物车中还有这些其他商品，但前提是该颜色是我们的“首映销售”颜色之一，除了等等等等...... ” - 你知道商业‘逻辑’是怎样的！ ;)
在这些情况下，我通常只是接受这样一个事实，即仅在业务层进行一些额外的验证，并确保有一种方法可以让这些错误在发生时传播回 UI 层（您将无论如何都需要该通信通道，无论如何都要报告持久层错误）。
Regarding "Edit 1" - I've encountered exactly that problem many times. I agree with you completely: there are multiple places where the same validation must occur.
The way I've resolved it in the past is to encapsulate the validation rules somehow. Metadata/XML, separate objects, whatever. Just make sure it's something that can be requested from the business objects, taken somewhere else and executed there. That way, you're writing the validation code once, and it can be executed by your business objects or UI objects, or possibly even by third-party consumers of your code.
There is one caveat: some validation rules are easy to encapsulate/transport; "last name is a required field" for example. However, some of your validation rules may be too complex and involve far too many objects to be easily encapsulated or described in metadata: "user can include that coupon only if they aren't an employee, and the order is placed on labor day weekend, and they have between 2 and 5 items of this particular type in their cart, unless they also have these other items in their cart, but only if the color is one of our 'premiere sale' colors, except blah blah blah...." - you know how business 'logic' is! ;)
In those cases, I usually just accept the fact that there will be some additional validation done only at the business layer, and ensure there's a way for those errors to be propagated back to the UI layer when they occur (you're going to need that communication channel anyway, to report back persistence-layer errors anyway).