我正在努力将我的一页转换为 3 层。
我认为优点是它更有条理。
我对正在发生的事情感到困惑，因为我现在有 3 层，但我意识到我并不清楚什么是 3 层。
这是我知道或认为我知道的
数据访问层 = 获取所有连接/值
业务访问层 = 从 DAL 运行这些连接和值。不确定，但这里是否检查错误？
Presentation layer = 这是我比较困惑的地方...这部分调出BAL？如果是这样，为什么还要有 3 层？
【问题讨论】：
表示层与用户交互，获取他们的请求并向他们显示信息。让我们以银行应用程序为例。用户想要登录他们的帐户、获取余额并转移一些发现。
表示层：给用户一个登录提示，获取用户的登录信息，告诉他们他们登录成功，显示他们的余额，为他们提供转移资金的选项，获取转移细节，告诉用户转移是批准。
业务访问层：验证用户的登录信息。计算向用户显示的余额。决定允许转移并批准。
数据访问层：存储用户的登录信息。存储账户余额信息、持有资金等。
基本上：
数据访问层存储信息。业务访问层决定检索哪些信息，根据它做出决策，传递结果。表示层从用户那里获取信息并将信息提供给用户。
【讨论】：
这里的这篇文章好像总结的不错：http://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture
我要强调的要点是，您可以在不同的环境中运行每一层。您可以使用 asp.net 在网络服务器上运行您的表示层。您可以在另一台服务器（应用程序服务器）上运行您的业务访问层，可能使用 Windows 服务或 WCF 服务等。最后一层可以位于数据库服务器上或附近。
能够将层分离到不同的物理位置的优势意味着您可以提高可扩展性。例如，您的网络服务器正在处理大量请求。您决定有两个网络服务器来调用您的业务访问层。
另一个优点是可维护性。如果所有数据访问代码彼此相邻，则更容易调试数据访问层问题。您有一个项目可能会将代码减少三分之一，以便更轻松地找到您要查找的内容。
另一个优势可能是可交换性。假设您不想再使用 asp.net。您可以换入一个 php Web 层，并使其更轻松地与您的 .NET 业务逻辑进行通信。
基本上我提到的优势是模块化/粒度优势。
【讨论】：
首先，“层”不是“层”的同义词。
层是逻辑上的分隔。
层是一种潜在的物理分离，通常在机器或进程级别。
（见：http://pranshujain.wordpress.com/2006/09/15/layers-and-tiers/）
=======
除了这三层的原因之外，您还可以随意更换它们。例如，您可能有多个表示层（Web、移动、桌面应用程序）。此处的目的是将演示文稿与其他所有内容分开，以便您可以更改业务逻辑，而无需重做所有不同的演示文稿代码。
业务对象层用于封装和执行所有常规逻辑。例如，您可能会说生日必须早于今天的日期。许多开发人员喜欢将其与存储和展示分开。
数据访问层负责将您的数据从业务对象编组到您的实际存储机制中。想法是您可以决定将内容存储在 SQL Server 或 Oracle 或平面文件中，而应用程序的其余部分不应该关心任何一种方式。
============
所有这些层都是必要的吗？不，但是对于大量应用程序，当需要更改时，它们会有所帮助。
现在，关于层级。桌面或浏览器可以被视为一层。 Javascript 代码和 HTML 将在此处执行。如果您有一个桌面应用程序，那就是它所在的地方。
另一层是您的 Web 服务器或 Web 服务接口。这负责提供用于呈现和使用客户端的 html。它通常包含 Presentation 呈现和业务对象层。
另一层是您的实际存储机制。例如 SQL Server 或 Oracle。
您完全有可能拥有 5 或 6 个不同的层，具体取决于您的架构有多先进（或草率……）；但是这个数字通常是 2 并且不超过 3。
您也完全有可能只有一层或十二层。但是，这里的数字通常是 2 到 3。同样，这取决于您的架构。
【讨论】：