使用存储过程作为业务逻辑层

Question

我正在使用的公司正在使用存储过程（在MsSQL服务器后端）作为其业务逻辑层。实际的业务逻辑DLL只是调用sProcs并基本上管理用户界面（事件，数据绑定等）

我认为设置有问题，尽管我不知道如何向同事解释。顺便说一句，该系统的工作。

我工作场所的“最佳实践”错误吗？或者我只是在推崇这一点？

Answer 1

GaiusSensei - 只要业务领域能够应对业务实践中的地震变化，那么以这种方式工作就很好。我认为SP和BLL dll之间的辩论仍然很盛行，毫无疑问，这个主题中双方都会有很多。然而，从我自己在过去10年一系列项目的经验，这里是我的意见支持BLL DLL的方法：包含在BLL

• 逻辑可以 存储介质和 的“不可知”因此，更灵活地改变 （寿多久出现这种情况是 值得商榷）
• 更细粒度的控制业务 权限在一系列依赖于 数据存储 应用。我的意思是核心 表的完整性必须是 保持在特定水平 它在业务 应用程序中使用。
• BLL逻辑可封装在自己的 包含的类别中，该类别可在业务的其他领域和/或项目中重复使用 。这个类甚至可以 写成一个密封类或 扩展取决于你的目标 “观众”
• 单元测试 - 这（在我的经验 ）是一个黑色的艺术，如果使用 SP的内部。在java/c＃下，这个 是标准的，现在有些人会说 强制性的练习。
• 可维护性。通过保持一个BLL DLL中以及 举办接口 情况下，你可以很容易为 支持开发者来扩展你的 类，而不会破坏现有的 逻辑
• 可移植性。您的BLL（取决于 的语言实现）可以是在各种平台上托管的 。 同样， implemetation数据存储区的注入可以 字面上是从XML文件 任何到MySQL，MSSQL postgres的等 等
• 标准化。数据架构师 可以精确地定义每个数据应该从 数据库中获取的数据以及应该如何保存每个项目 （这将会更好地位于DAL dll中）。因此， 进入新开发商的成本以及经验丰富，对该项目的减少很多 。

这个名单还在继续，但这些都是我采用BLL方法的头等PROS。

展望FWD的许多自旋在这一个:)

吉姆

[编辑] - 我也想补充一点，BLL应该也不排放任何UI信息，比其他（如你提到）来传达事件等。每个UI层（与目标设备 - 浏览器/移动设备/工厂有关）应该引用BLL并且与数据一起做它自己的'thang'。我进一步补充说BLL下面是你的DAL层。该层可以被认为是底层数据存储的1-1参考。

Answer 2

我们这样做。

这是因为我们支持用户使用预期软件以外的程序（如SQL Management Studio，osql和Excel）连接到数据库的场景。

当您直接连接到数据库不超过数据存储的数据库时，您可以将所有内容搞乱，因为没有任何规则可以阻止您。这些规则只存在于使用此数据库的程序内部，如果您不使用该程序，则可以使用I-can-write-to-this-table权限来执行愚蠢的（或有趣的）操作。

当您只有执行存储过程的权限时，您不能。
我个人认为这是一个更好的方法。

Answer 3

我要说的是，存储过程不适合自己的单元测试和重构几乎与业务层逻辑中说.NET/JAVA。我会尽可能地将逻辑从数据库中排除出去，主要的异常是DBMS擅长的基于操作的固有操作。

Answer 4

（我加的“主观”的标签）

我更喜欢使用存储过程，除了在小应用程序，我马上拿出，因为在存储过程中插科打诨需要一点额外的时间。

Christopherous 5000：你仍然可以做单元测试与存储过程

我倾向于这两个类似的问题的答案一致：

• Business Logic: Database or Application Layer

• Should the data access layer contain business logic?

Answer 5

这听起来像你的业务层实际上是数据层和应用程序中没有一个业务层，但我离题...

最佳实践是被高估，并随着时间的推移而改变。如果他们在做什么，他们满足于此，那么没有什么可以做的。

我不能告诉你有多少项目，我一直在这里新来的家伙来到船上，并认为目前的体系结构需要改变。我自己做了几次。这不是一个好地方。现状会与你抗争到最后。如果你真的想改变现有的系统，建立一些可信度。在3到6个月内开始提出更好的方法来处理一些现有的基础设施。如果你真的不喜欢当前的架构，那就离开公司。

该应用程序是用最好的意图书写的。原始开发人员受到时间，经验和技术的限制。

像你描述的应用程序的应用程序是成熟的学习机会。注意失败点，从成功中学习。你会惊讶于你学到的东西。

Answer 6

我认为存储过程很好，作为您的业务逻辑的一部分。我不认为你需要在一个DLL中拥有整个业务逻辑。但是，如果您有一个管理UI的业务层，我认为您需要用某种框架将UI管理与业务层分开。分离应该是功能性的，不要将数据嵌入到存储过程或业务逻辑中，反之亦然。我也认为，如果你有其他程序，如Excel或报告，通过离散数据源，Web服务或其他方式访问他们应该进入的数据。

我用它来处理带有大型机的客户端服务器系统，在这些系统中，您可以实现三层真正的分离和真正的骨干不灵活性。现代应用程序需要在实现上更加开放，并且在所有层都有业务规则，特别是验证。这并不意味着你的设计模型不能分离，只是像'空白或星期几'这样的业务规则必须在UI，业务层和数据中实现。

如果你有什么作品，只是想象如何使用它继续前进。

Answer 7

这取决于。

这取决于您所称的业务逻辑。

某些事情需要在数据库中强制执行 - 尤其是任何其他进程将假设数据库呈现的性质的东西。

如果数据库的所有用户都假定当一个计费方的最后一个后代被停用时，计费方状态需要改变，那么这需要在数据库中执行 - 或者在唯一的SP中执行操作或触发器的方式，或约束或其他。这是一种事情 - 低层次的业务逻辑，它在业务层面上是非常关键的数据完整性逻辑 - 这在数据库中是可以实现的。

高级业务逻辑不适合数据库 - 例如，当患者取消最后一次约会并需要重新召回列表时 - 这不是数据完整性问题 - 系统的所有呼叫者都不承担没有约会的患者必须在召回清单上。

区别很微妙，这就是为什么人们在数据库中存在“业务”逻辑的困难。我只推荐那些假设数据库在数据库周边向数据库中的所有用户提供保护并呈现给数据库的东西 - 该业务逻辑位于DAL层之下，并且是基本数据库设计的一部分。我仍然在传统体系结构中倡导一个高于此值的业务盲DAL和一个真正的BLL。

话虽这么说，当DAL真的很简单的SP泵抽取数据库中的高级业务逻辑时，当然也是可能的，而且当你这样做时，它不太清楚哪些事情是低级的，这是高层次的（除非你有两个数据库，一个建立在另一个之上 - 这不一定是一个可怕的想法）。您已经有效地将您的业务逻辑的一部分写入了SQL，而不是传统的客户端应用程序。

这并不一定意味着您的图层耦合过紧或者您的架构很糟糕 - 就像任何系统一样，不同图层的语言选择不一定指向架构问题。只有通过查看图层，您才能确定是否存在架构问题。

Answer 8

如果您的同事想要重用MySQL的业务层，该怎么办？你会告诉他这是不可能的，因为一些业务层驻留在SQL Server中。