我已经看到了将业务逻辑从数据访问层（存储过程，LINQ等）转移到业务逻辑组件层（如C＃对象）的趋势。
这被认为是这些日子做事的“正确”方式吗？如果是这样，这是否意味着某些数据库开发人员的职位可能会被淘汰，以支持更多的中间层编码职位？ （即更多c＃代码而不是更长的存储过程。）
答案 0 :(得分：31)
如果应用程序很小且寿命很短，那么就不值得花时间来抽象层次中的问题。在较大的长期应用程序中，您的逻辑/业务规则不应与数据访问相关联。随着应用程序的增长，它会产生维护噩梦。
将问题移到公共图层或也称为Separation of concerns，已经存在了一段时间：
维基百科
关注点分离是 可能是由Edsger W. Dijkstra创造的 在他1974年的论文“论的角色 科学思想“1。
对于应用程序架构，一本很好的书是Domain Driven Design。 Eric Evans详细介绍了应用程序的不同层。他还讨论了数据库阻抗以及他所谓的“有界上下文”
有界上下文
博客是一个显示从最新到最旧的帖子的系统，以便人们可以发表评论。有些人会将此视为一个系统，或一个“有界上下文”。如果您订阅DDD，可以说博客中有两个系统或两个“Bounded Contexts”：评论系统和发布系统。 DDD认为每个系统都是独立的（当然两者之间会有相互作用），因此应该对其进行建模。 DDD为如何将问题分成适当的层提供了具体的指导。
您可能感兴趣的其他资源：
在我有机会体验The Big Ball of Mud或Spaghetti Code之前，我很难理解为什么应用程序架构如此重要......
正确的做事方式始终取决于应用程序的大小，可用性要求和使用寿命。要使用存储过程或不使用存储过程... nHibrnate和Linq to SQL等工具非常适合中小型项目。为了使自己清楚，我从未在大型应用程序上使用过nHibranate或Linq To Sql，但我的直觉是应用程序将达到需要通过视图，存储过程等在数据库服务器上进行优化的大小。保持应用程序的性能。要做这项工作，将需要具有开发和数据库技能的开发人员。
答案 1 :(得分：18)
数据访问逻辑属于数据访问层，业务逻辑属于业务层。从设计的角度来看，我不认为将这两者混合起来是一个好主意。
答案 2 :(得分：4)
分层确实不自动意味着不使用存储过程进行业务逻辑。这种分离同样是可能的：
表示层：.Net，PHP，无论
业务层：存储过程
数据层：存储过程或DML
这非常适用于Oracle，例如，业务层可以在与数据层不同的模式中的包中实现（以强制正确分离关注点）。
重要的是关注点的分离，而不是每个级别使用的语言/技术。
（我希望这种异端邪说能够全面爆发！）
答案 3 :(得分：1)
这实际上取决于要求。无论哪种方式，只要它是 NOT “在按钮后面”就像它一样。我认为存储过程对于需求不断变化的“经典”客户端服务器应用程序更好。严格的中间“业务逻辑”层对于需要具有高度可扩展性，在多个数据库平台上运行的应用程序等更好。
答案 4 :(得分：1)
如果您正在构建分层架构，并且架构包含专用业务层，那么您当然应该将业务逻辑放在那里。但是，您可以向任何五位设计师/架构师/开发人员询问“业务逻辑”究竟是什么，并获得six different answers。 （嘿，我自己也是一名建筑师，所以我一方面知道'，另一方面又知道'！）。导航数据层或业务层的对象图部分？取决于您使用的EAA patterns，以及您的域对象究竟有多复杂/聪明。或者它甚至可能是您演示文稿的一部分？
但更具体地说：数据库开发工具往往落后于Eclipse / Visual Studio / Netbeans /;对于大规模开发而言，存储过程从未如此舒适。是的，当然你可以对TSQL，PL / SQL＆amp; c中的所有内容进行编码，但需要付出代价。更重要的是，在一个解决方案中使用多种语言和平台的价格会增加维护成本和延迟。另一方面，将数据访问移到DBA的范围之外可能会引起其他麻烦，特别是对于具有任何可用性要求的共享基础架构环境。但总的来说，是的，现代工具和语言目前正在将逻辑从数据（基础）层转移到应用层。我们必须看看它的效果和规模。
答案 5 :(得分：0)
我看到这种趋势的原因是LINQ和LINQ to SQL ORM为存储过程提供了一种不错的类型安全替代方案。
“正确”是指您是否从这样做中受益。
答案 6 :(得分：0)
是的，业务逻辑应该在业务逻辑层中。对我来说，这是使用存储过程的一切最大的缺点，从而将一些业务规则移动到数据库，我更喜欢在BLL中使用DLL只与DLL进行通信
答案 7 :(得分：0)
分离你的图层总是一个好主意。我不能告诉你我看过很多写入sproc的业务逻辑非常粗糙的存储过程的次数。此外，如果您因任何原因修改了复杂的存储过程，则可能会破坏使用它的一切。
我们公司的开发人员正在转向使用EF的LINQ并解除存储过程，除非我们绝对需要它。 LINQ和EF使我们的层分离更容易......当EF不困难时。但那是另一个咆哮。 ：）
答案 8 :(得分：0)
数据层中可能总会存在某种级别的业务逻辑。数据本身就是某些逻辑的表示。例如，主键通常基于业务逻辑规则创建。
例如，如果您的系统不允许订单有多个客户是业务逻辑的一部分，但它也存在（或应该）在数据层中。
此外，出于效率原因，最好对数据库本身执行某些类型的业务规则。这些通常是存储过程，因此存在于数据层中。一个例子可能是一个触发器，如果一个客户一年花费超过X美元，或者一个货物发送到一个账单上，则会触发。
其中许多规则也可以在业务层中处理，但它们也需要数据层组件。这取决于您的错误处理位置。
答案 9 :(得分：0)
数据层中的业务逻辑在客户端/服务器应用程序中很常见，因为 本身没有业务逻辑层（除非你真的可以，严重阻止任何人连接到数据库之外的数据库）应用）。现在Web应用程序更常见，您会看到更多的3层和4层应用程序（客户端+ Web服务器+应用程序服务器+数据库服务器），更多公司正在遵循最佳实践并在其自己的层中整合业务逻辑。我认为数据库开发人员的工作量不会减少，他们可能只会成为编写业务逻辑层的人（并让ORM工具编写大部分数据库层）。
答案 10 :(得分：0)
在规划创建业务规则的位置时，还需要考虑技术原因/限制。
在大多数LOB应用程序中，集中化和性能促使开发人员将自己的数据库用作主要业务层，因此从某种意义上说，DAL和BL是混合或统一的。
一个典型的例子是计算租赁项目的当前位置的字段，一条信息应该可用于一个或多个列出的项目，使得具有用户定义函数的SQL视图成为最强大的候选者。遵守规则。
上述示例当然是有效的，如果特定的数据库设计和流程实现是首选，但我只想指出，在现实世界中，我们选择基于技术限制和其他原则，比我们组织的更多我们的代码。
答案 11 :(得分：0)
完美的世界不存在。这是关于优雅与更好的方式。 在数据访问层内执行复杂的SQL查询比使服务多次询问数据然后合并和转换它们更具性能。当您进行复杂查询时，您将业务逻辑放在这些查询中。