我们正在开发一个网络应用程序。我们希望可能将我们在这里所做的工作重用于将使用相同数据库的不同应用程序，并使用相同的业务规则来读取和写入所述数据库。
哪种设计更正确
让 UI 调用 Web 服务，该服务将使用包含业务逻辑的业务对象，该业务对象将与数据访问层对话。
让 UI 使用包含业务逻辑的业务对象，这将调用 Web 服务，然后与数据访问层对话。
让 UI 用户业务对象包含业务逻辑，这将与数据访问层对话。
【问题讨论】：
标签： web-services web-applications data-access-layer business-objects business-logic-layer
根据您的描述，您没有提供需要使用 Web 服务层的原因。假设您的 UI 系统可以访问您的数据库，即在防火墙后面的同一网络中，您的网站 UI 代码（我假设是服务器端）将使用的基本业务对象层将满足您的要求。
当您的 UI 系统和数据层之间的距离开始跨越数据访问层或业务逻辑层将开始遇到困难的边界时，引入 Web 服务层。
【讨论】：
就设计是否“正确”而言，如果没有完整的上下文，就不可能对设计的正确性给出 100% 的答案。有哪些要求（功能性和非功能性）？你想实现什么设计目标？每个目标有多重要？
您的问题提到的唯一目标是您希望将业务逻辑重用于另一个应用程序。当我想以标准方式重用应用程序的业务逻辑时，我会选择 Web 服务。因此，仅根据您的一项要求，我会说选项 1（ UI->Web Service->Business Layer->Data Layer ）是一个不错的选择。
【讨论】：
签出：http://www.icemanind.com/layergen.aspx
应该采用的方式是，您的 UI 层位于顶部，数据层位于底部，业务层位于两者之间。每层只能与它下面的层通信。所以 UI 只与业务层对话……业务层只与数据层对话。你的 UI 不应该和数据层对话，你的数据层也不应该和你的 UI 交互。
除非你有理由使用网络服务，否则我不会。
【讨论】：
我会说第三个。我倾向于将 Web 服务视为另一个表示层。
这样想：您有一个 Web UI，它调用您的业务层代码来执行诸如创建新用户 (User.Add)、查找与给定描述匹配的所有产品 (Products.FindByDescription) 等操作.
您现在可以重复使用相同的业务层代码来构建一组面向公众的 Web 服务，以供第 3 方使用。可以有一个添加用户的方法 - 调用您的内部 User.Add() 方法，另一个查找产品等。
您得到的是一组并行的表示/接口，用于相同的基础数据和业务逻辑。
在幕后（完全超出 Web 服务或 UI 层的范围），业务层调用数据访问层，负责物理查询数据库。如果您要更改为不同的 DBMS，理想情况下（理论上）您应该能够为新数据库重建数据层并让一切正常工作。
您的业务层包含规则，例如用户名长度必须为 4 到 15 个字符；用户只能搜索和加载他们有权访问的商店中的产品；等等
如果您决定更改业务规则（例如允许用户在其所在州的任何商店中搜索产品），那么您只需更改一次即可，无需触摸网络服务或 UI 即可它工作。
【讨论】：
不要将逻辑设计与物理设计混为一谈。逻辑设计在层和物理设计层上运行。 Web Service 不是一个层。它只是一个层次。 在逻辑设计中有标准方法：UI层-> BL层-> DAL 在物理设计中，所有层都可以驻留在一个连接本地数据库的客户端应用程序中，或者可以分布在远程层上。但是对于分布式应用程序，通常会多添加一层：应用程序层，它隐藏了 BL 层的网络通信。
【讨论】：
从逻辑上讲，Web 服务属于 UI 层。想想“用户”不仅是一个人，而且是另一个系统，它就变得清晰了。在这些逻辑层之间保持严格的关注点分离将使您能够轻松地实现和维护您的应用程序。
【讨论】：
你听说过服务层吗？我认为您可以为您的事务和操作使用服务层，使用外观层可以帮助您在访问业务层后直接或间接地隔离和管理从 UI 到数据访问层的访问。这取决于您的要求。
【讨论】：