业务逻辑层（BLL）有什么用？

在学习数据库应用程序的良好实践时，我经常遇到所谓的“业务逻辑层”的拥护者，我试图确定对我的项目来说最好使用一个（这是一个小型的个人项目）。我的问题在于，我无法想到BLL要做DAL无法处理的任何事情（执行查询并将结果映射到对象），所以我的BLL只是在不做任何事情的情况下调用DAL。

也许我对DAL也应该做的事情是错误的。但是，无论如何，数据库管理应用程序中的BLL应该具有什么样的功能？

对于我的小型应用程序，我的BLL通常以传递到DAL的方式开始。我可以。当我“发现”业务规则时，BLL是我放置它们的地方。在编写测试时，我最终还发现BLL需要很多东西。对于我自己的个人应用程序，我制定了业务规则，而BLL仍然放在我的位置。对我来说，BLL是随着时间而增长的。我从事项目的时间越长，其BLL越大。

我会考虑将BLL和DAL合并为一个小型项目吗？我可能会改变，除了我改变发型的频率与改变DAL技术的频率一样，并且我希望有一些东西可以隔离我的客户端代码。

BLL将处理属于业务域的一部分，而不是数据库的一部分，而不是UI的一部分（通常）。例如，使用客户的年龄来确定他们是否有资格享受特殊的老年人折扣。DAL不应该这样做，它应该只是检索客户数据，然后在BLL完成工作后将其与折扣数据一起存储。DAL应该更多地关注CRUD。在小型应用程序中，这两个问题可能会重叠。

安德鲁，

当您进行域驱动的开发并专注于域的核心活动时，您将最终获得业务逻辑层。如果除去表示层（GUI，Web）和基础结构层（数据库，网络连接等），您将获得属于域的核心活动，例如将钱存入银行帐户。现在，如果您已经对业务层进行了建模，并将其与表示和基础设施隔离开来，则可以轻松地将其移植到其他用途，例如Web或移动设备。这是一种思考开发的干净方法，而且据我所见，不幸的是，它并没有得到如此认真的对待。

我建议您先接触Eric Evans-域驱动设计，这是一本很好的书，证明了将开发工作集中在域上是合理的。诚然，这是一个半途而废的阅读过程，但是它的确建立了势头，并且对于开发人员在当今系统中的错误之处抱有强烈的信念。

没有什么表明您必须具有一定数量的层或层。这完全取决于项目的复杂性。看一下许多MVC示例应用程序，例如书呆子晚餐或唱片商店。它们都使用2层，因为对于处理逻辑很少的应用程序来说，这没有任何意义。

但是，即使您的应用很小，也可能会通过通常是业务层的第三层将数据层从表示层中抽象出来而受益。这使您可以在单个位置而不是整个表示层进行更改。

假设您决定将您的ORM从Linq更改为SQL，再更改为Entity Framework（或nhibernate）。在业务层中更改它可能比在表示层中更改要容易，因为表示趋向于与其表示模型紧密结合。

如果您了解MVC，那就是Model View Controller，您可以用类似的术语来考虑您的应用程序体系结构。该模型类似于您的数据层，表示层是视图，业务层是控制器。

补充荒凉星球有关域驱动设计的答案：

还请查看与域驱动设计概念非常一致的Onion Architecture。

请注意，业务逻辑“层”是洋葱的核心，每个基础结构层（例如数据访问层）都是其外部依赖关系。这有助于进行大量测试，因为您应该能够模拟所有外部基础结构依赖性并完全测试您的域逻辑。

我认为：“纯逻辑解决方案”所在的业务逻辑层。其余只是基础设施的实现细节。

但是，某些应用程序可能不需要这种架构。如果您所有的应用程序都是数据集CRUD操作，那么您的“纯概念性解决方案”实际上可能是空的，您所需要的只是数据库编辑前端。在这种情况下，您最好只专注于DAL和UI层。

这个问题的答案是（IMHO）：“我可以完全替换我的DAL，而不必重写任何业务逻辑代码”吗？

将其视为您的表示层-考虑将GUI更改为另一层是很常见的，厚桌面GUI被替换为Web客户端，而Web客户端被替换为iPhone应用程序。对于BLL / DAL这样的想法并不是很常见，因为除了可能非常相似的东西（例如，用MySQL替换了一个SQLServer DB）之外，它们从未真正被交换过，但是如果您认为必须将DB更改为分布式存储，使用API​​访问的服务，您可能会更清楚地了解各层之间的交汇处。