我理解三层体系结构的好处（例如，在一个层中更改代码通常不会影响其他两个层中的代码），但我不明白为什么UI layer不好主意（在某些情况下）直接访问`数据层。
a）我可以想到UI只应与BLL layer交谈的几个原因：
这种方式UI开发人员不需要知道DB schema的详细信息，因为BLL layer使用自定义对象抽象数据库表。
此外，BLL layer通常会在将传入数据传递到另一层之前处理/验证传入数据
还有其他原因吗？
b）但是，如果同一个开发人员正在编写所有三个层，那么UI layer不应该直接访问data layer的确有任何理由（如果它不需要{{1}处理/验证数据）？
谢谢
答案 0 :(得分：4)
作为一名数据库和服务器开发人员，我有一个简单的答案：您不能再在一个地方查看所有数据库访问权限，现在数据库更改将影响多个模块。
答案 1 :(得分：3)
如果将图层保持解耦，则可以在不重新编码UI图层的情况下切换数据库引擎等组件。同样，即使中间层不必处理/验证数据，它也可用于从其他来源（其他数据库，网络资源等）检索其他数据，而无需重新编码UI层。
这是一个很好的做法。它允许您更改系统以进行缩放或调整，而对其他部分的影响最小。
答案 2 :(得分：2)
安全。 BLL应该可以从客户端访问，并且只公开您希望客户端上的人员使用的方法。如何在客户端代码中安全地存储数据库连接字符串？
根据您使用的语言和框架，您可以使BLL方法仅接受预先认证的呼叫。
我假设UI是客户端应用程序而不是网站。
答案 3 :(得分：2)
有些应用程序足够小，以至于n层架构过度。当你开始使用更大的应用程序时（记住小应用程序往往会成长为大型应用程序），那么重要的是：
最重要的是能够在不需要连接数据库的情况下测试代码，从而使您能够真正隔离被测对象。
至于最小化变更的影响，随着您的需求变化，您的设计可能会发生变化。如果逻辑和数据访问分散在您的应用程序中，那么小的更改会带来重大风险（以及额外的测试工作）。
现在，如果你是一个单独的商店并且不希望你的软件以任何显着的方式增长，那么就没有必要为更复杂的设计做好准备。
另一方面，出于某种原因，它们被称为“最佳实践”。
答案 4 :(得分：1)
最后，这种类型的决定归结为偏好（显然），但它也提醒每个架构决策需要追溯到某个目的。这些目的或要求可以有多种背景，从商业到技术，但重要的是他们应该在那里，原因很简单，每当你发现自己质疑手头的架构中的具体细节（决定）时，你可以追踪决策背后的动机。
在进行架构审核时，我经常会找到一个如你所描述的3层UI / BLL / DAL架构，而且除了“其他人都在做”之外没有其他原因，“这是微软的方式”，等等。 cetera ad nauseam。它是一个很好的架构（或层模式），但它并不是万能的（因为它似乎不存在于任何地方）。
我想到的一些问题：自定义对象在哪里“抽象数据库表”（引用），以及您公开这些对象的级别？这些DTO或BLL中的对象是否由DAL填充？ UI是否知道这些对象（直接引用），还是BLL隐藏了它们？ BLL中的对象是否持久感知？您在层之间的引用是什么样的？绘制高级图片可以在这里提供帮助。
已经发布了一些不做你建议的理由;虽然这些都是有效的，但每个异议都可以通过变通方法（或10）来减轻。鉴于一个绿地情况，我实际上更喜欢沿着这些方向做一些事情，使数据访问尽可能（在架构上）精益。我发现这使得解决方案保持敏捷，并且非常适合在需求发生变化时进行更改（如他们一直所做的那样）。
一些建议：如果您要继续这样做，请尝试明确地将读取与写入分开（来自命令的查询，来自事务的问题，选择您的术语）。将UI链接到DAL的另一种方法是创建一个非常物的服务层（对于一个模糊的术语，这是怎么回事？实际上，这就是为什么我有时将其称为“操作”层，除了消除歧义之外没有其他原因）可以直接从数据访问层获取所需对象，也可以在操作需要时调用业务层。这样，您仍然可以通过一种方式定义UI与底层基础架构之间的所有交互，但您可以单独优化每个操作。