【发布时间】：2010-10-10 17:04:38
【问题描述】：
我看到了将业务逻辑从数据访问层（存储过程、LINQ 等）移到业务逻辑组件层（如 C# 对象）的趋势。
这被认为是当今做事的“正确”方式吗？如果是这样，这是否意味着一些数据库开发人员职位可能会被淘汰，取而代之的是更多的中间层编码职位？ （即更多的 c# 代码而不是更长的存储过程。）
【问题讨论】：
标签： sql sql-server design-patterns architecture
【发布时间】：2010-10-10 17:04:38
【问题描述】：
如果应用程序很小且生命周期很短，那么就不值得花时间在分层中抽象关注点。在较大的、长期存在的应用程序中，您的逻辑/业务规则不应与数据访问耦合。随着应用程序的增长，它会造成维护的噩梦。
将关注点移至公共层或也称为Separation of concerns，已经存在了一段时间：
维基百科
术语分离关注点是 可能由 Edsger W. Dijkstra 创造 在他 1974 年的论文“论 科学思想”1.
对于应用程序架构来说，一本很棒的书是Domain Driven Design。 Eric Evans 详细分解了应用程序的不同层。他还讨论了数据库阻抗和他所谓的“有界上下文”
限界上下文
博客是一个系统，它显示从最新到最旧的帖子，以便人们可以发表评论。有些人会将其视为一个系统，或一个“限界上下文”。如果您订阅 DDD，有人会说博客中有两个系统或两个“限界上下文”：一个评论系统和一个发布系统。 DDD 认为每个系统都是独立的（当然两者之间会有交互）并且应该这样建模。 DDD 就如何将关注点分离到适当的层提供了具体指导。
您可能感兴趣的其他资源：
- Domain Driven Design Quickly
- Applying Domain Driven Design and Patterns
- Clean Code
- Working Effectively with Legacy Code
- Refactor
在我有机会体验The Big Ball of Mud 或Spaghetti Code 之前，我很难理解为什么应用程序架构如此重要...
正确的做事方式始终取决于应用程序的大小、可用性要求和生命周期。使用存储过程或不使用存储过程... nHibrnate 和 Linq to SQL 等工具非常适合中小型项目。为了清楚起见，我从未在大型应用程序上使用过 nHibranate 或 Linq To Sql，但我的直觉是应用程序将达到需要通过视图、存储过程等在数据库服务器上进行优化的大小以保持应用程序的性能。要完成这项工作，需要同时具备开发和数据库技能的开发人员。
【讨论】：
-
在与一些涉及更多的架构进行了更密切的合作之后，我可以说这是一个比我更好的答案。
-
在 Asp.net MVC4 中我使用了区域。每个区域都是一个小应用程序，支持由主应用程序封装的整体流程。每个区域都有自己的 DAL 和一个业务层来获取 DAL 方法。以及我尝试将类似的 DAL 方法放在应用程序的整体主要区域（区域外）。我注意到我开始向 DAL 添加业务逻辑以处理事务编辑，因为我想在确保满足条件的同时避免打开和关闭多个连接。如果它包含在 MVC 应用程序的小区域中，这样可以吗？
-
我只有几年的实际经验，所以虽然我仍在掌握编码，但我也在努力学习设计和架构的最佳实践。我还没有完全到那里，但是当我从头开始构建项目的任务时，我不得不快速学习。
数据访问逻辑属于数据访问层，业务逻辑属于业务层。从设计的角度来看，我不认为将两者混合是一个好主意。
【讨论】：
-
也许不是，但这不排除在存储过程中构建您的业务层，也不要求使用 C# 代码。
-
当然不是。有时可能会为业务逻辑使用存储过程，但您要付出代价。您应该尽量保持图层分开。
-
我真的不明白数据访问和“业务”之间的区别。
-
对于任何未来的读者，请注意此建议。这非常接近于贫血的领域模型。 Foo 相关的方法应该在 Foo 的模型中。除非您有充分的理由，否则不要将实体作为 getter 和 setter 的包，并将它们的方法放在另一层。在过去一年与一些涉及更多的系统进行更密切的合作后吸取的经验教训。
分层不自动意味着不使用存储过程进行业务逻辑。这种分离同样可能：
表示层：.Net、PHP 等
业务层：存储过程
数据层：存储过程或 DML
这与 Oracle 配合得非常好，例如，业务层可以在与数据层不同的架构中的包中实现（以强制适当地分离关注点）。
重要的是关注点的分离，而不是每个级别使用的语言/技术。
（我希望会因为这种异端邪说而受到彻底的抨击！）
【讨论】：
-
在净化之火中燃烧你这个异端！ :0) (+1)
-
你可能是一个控制狂（阅读：数据库管理员）并且喜欢一切都在你的控制之下:-) 如果你可以将 GUI 层移动到数据库中，你可能也会这样做！
-
@joedotnot - 你应该这么说很有趣：我使用 Oracle Application Express，它从数据库中保存的元数据生成 HTML 页面。幸福！
-
这三个 cmets 在一个阴沉的星期二晚上让我振作起来 - 干杯！
完美的世界并不存在。这是关于优雅与效果更好的对比。 在数据访问层内执行复杂的 SQL 查询比让服务多次询问数据然后合并和转换它们的性能要高得多。当您进行复杂查询时，您将业务逻辑放入这些查询中。
【讨论】：
这真的取决于要求。无论哪种方式，只要它不是“在按钮后面”就可以了。我认为存储过程更适合具有不断变化的需求的“经典”客户端服务器应用程序。严格的中间“业务逻辑”层更适合需要非常可扩展、在多个数据库平台上运行等的应用程序。
【讨论】：
如果您正在构建一个分层架构，并且该架构包含一个专用的业务层，那么您当然应该将业务逻辑放在那里。但是，您可以询问任何五位设计师/架构师/开发人员实际上是什么“业务逻辑”，并得到sixdifferentanswers。 （嘿，我自己也是一名建筑师，所以我知道“一方面，另一方面”！）。导航对象图是数据层还是业务层的一部分？取决于您使用的是哪个EAA patterns，以及您的域对象到底有多复杂/聪明。或者它甚至可能是您演示文稿的一部分？
但更具体而言：数据库开发工具往往落后于 Eclipse/Visual Studio/Netbeans/；和存储过程对于大规模开发来说从来都不是很舒服。是的，当然您可以在 TSQL、PL/SQL 和 c 中编写所有代码，但要付出一定的代价。更重要的是，在一个解决方案中涉及多种语言和平台的代价会增加维护成本和延迟。另一方面，将数据访问移到 DBA 无法访问的地方可能会引起其他麻烦，尤其是对于具有任何类型可用性要求的共享基础架构环境。但总的来说，是的，现代工具和语言目前正在将逻辑从数据（基础）层转移到应用程序层。我们必须看看它的效果和规模。
【讨论】：
我看到这种趋势的原因是 LINQ 和 LINQ to SQL ORM 为您提供了一个很好的类型安全的存储过程替代方案。
什么是“正确的”是你是否从个人这样做中受益。
【讨论】：
是的，业务逻辑应该在业务逻辑层。对我来说，这是对所有内容都使用存储过程从而将一些业务规则移动到数据库的最大缺点，我更喜欢在 BLL 中使用该逻辑，让 DLL 只与数据库进行通信
【讨论】：
分离图层总是一个好主意。我无法告诉你有多少次我看到存储过程非常粗糙，因为大量业务逻辑写入存储过程中。此外，如果您出于任何原因修改复杂的存储过程，您就有可能破坏使用它的所有内容。
我们公司的开发人员正在迁移到带有 EF 的 LINQ 并取消存储过程，除非我们绝对需要它。 LINQ 和 EF 使我们的层分离变得更加容易……当 EF 并不困难时。但这是另一个咆哮。 :)
【讨论】：
-
EF 没有耦合到数据访问层？ ...或者是 EF是数据访问层吗？ ... ORM 创建对象 - 创建这些对象与实际业务逻辑不同吗？
数据层中可能总是存在某种级别的业务逻辑。数据本身就是其中一些逻辑的表示。例如，主键通常是根据业务逻辑规则创建的。
例如，如果您的系统不允许一个订单拥有多个客户，这是业务逻辑的一部分，但它也存在（或应该存在）在数据层中。
此外，出于效率原因，最好在数据库本身上完成某些类型的业务规则。这些通常是存储过程，因此存在于数据层中。例如，如果客户在一年内花费超过 X 美元，或者收货方与收单方不同，就会触发触发器。
其中许多规则也可能在业务层中处理，但它们也需要数据层组件。这取决于您的错误处理位置。
【讨论】：
数据层中的业务逻辑在客户端/服务器应用程序中很常见，因为实际上本身并没有业务逻辑层（除非您真的可以非常严重地阻止任何人连接到数据库之外的数据库）应用）。现在 Web 应用程序更加普遍，您会看到更多的 3 层和 4 层应用程序（客户端+Web 服务器+应用程序服务器+数据库服务器），并且越来越多的公司正在遵循最佳实践并将业务逻辑整合到自己的层中。我认为数据库开发人员的工作不会减少，他们可能会成为编写业务逻辑层的人（并让 ORM 工具编写大部分数据库层）。
【讨论】：
在规划在何处编写业务规则时，还需要考虑技术原因/限制。
在大多数 LOB 应用程序中，集中化和性能促使开发人员将其自身的数据库用作主要业务层，因此从某种意义上说，DAL 和 BL 是混合或统一的。
一个典型的例子是计算租赁项目当前位置的字段，一条信息应该可用于一个或多个列出的项目，使具有用户定义函数的 SQL 视图成为最强大的候选者遵守规则。
如果首选特定的数据库设计和流程实现，上述示例当然是有效的，但我只想指出，在现实世界中，我们根据技术限制和其他原则进行选择，而不是组织我们的代码。
【讨论】：