UI，业务逻辑层，数据层以及放置Web服务的位置

Question

我们正在开发一个Web应用程序。我们希望可以将我们在此处所做的工作重用于将使用相同数据库的不同应用程序，并使用相同的业务规则来读取和写入所述数据库。

哪种设计更正确

1. 让UI调用Web服务，该服务将使用包含业务逻辑的业务对象，该业务对象将与数据访问层通信。

2. 让UI使用包含业务逻辑的业务对象，该业务逻辑将调用Web服务，然后与数据访问层通信。

3. 让UI用户业务对象包含与数据访问层通信的业务逻辑。

Answer 1

不要将逻辑设计与物理设计混合在一起。逻辑设计在层和物理设计层上运行。 Web服务不是一个层。它只是一个层次。 在逻辑设计中，存在标准方法：UI层 - ＆gt; BL层 - ＆gt; DAL 在物理设计中，所有层都可以驻留在连接本地数据库的一个客户端应用程序中，也可以分布在远程层上。但是对于分布式应用程序，通常会增加一层：应用程序层，它通过线路从BL层通信中隐藏。

Answer 2

我会说第三个。我倾向于将Web服务视为另一个表示层。

以这种方式思考：您有一个Web UI，它调用您的业务层代码来执行诸如创建新用户（User.Add），查找与给定描述匹配的所有产品（Products.FindByDescription）等等。

您现在可以重复使用相同的业务层代码来构建面向公众的Web服务，供第三方使用。可以有一种添加用户的方法 - 调用内部User.Add（）方法，另一种方法来查找产品等。

您得到的是一组并行的演示文稿/接口，用于相同的底层数据和业务逻辑。

在幕后（完全超出Web服务或UI层的范围），业务层调用数据访问层，负责物理查询数据库。如果要更改为不同的DBMS，理想情况下（理论上）应该能够为新数据库重建数据层，并使所有内容都能正常工作。

您的业务层包含规则，例如用户名长度必须为4到15个字符;用户只能搜索和加载他们有权访问的商店的产品;等

如果您决定更改业务规则 - 例如允许用户在其所在州的任何商店中搜索产品 - 那么您可以在一次更改它，而不必触摸Web服务或UI来制作它有效。

Answer 3

根据您的说明，您没有提供使用Web服务图层的原因。假设您的数据库可以通过您的UI系统访问，即在防火墙后面的同一网络中，您的网站UI代码（服务器端，我假设）将使用的基本业务对象层将满足您的要求。

当UI系统与数据层之间的距离越过跨越数据访问层或业务逻辑层开始遇到困难的边界时，请引入Web服务层。

Answer 4

就设计是否“正确”而言，如果没有完整的背景，就不可能100％回答设计的正确性。有哪些要求（功能性和非功能性）？您想要实现哪些设计目标？每个目标有多重要？

您的问题提到的唯一目标是您希望将业务逻辑重用于其他应用程序。当我想以标准方式重用应用程序的业务逻辑时，我选择了Web服务。因此，仅根据您的一个要求，我会说选项1（UI-＆gt; Web服务 - ＆gt;业务层 - ＆gt;数据层）是一个不错的选择。

Answer 5

逻辑上，Web服务属于UI层。认为“用户”不仅是一个人，而是另一个系统，它变得清晰。保持严格区分这些逻辑层之间的关注点将使您能够轻松实现和维护您的应用程序。

Answer 6

结帐：http://www.icemanind.com/layergen.aspx

应该采用的方式是，您的UI层位于顶层，数据层位于底层，业务层位于两者之间。每个图层只能与其下面的图层进行通信。因此，UI仅与业务层进行通信......业务层仅与数据层进行通信。您的UI永远不应该与数据层交谈，您的数据层永远不应与您的UI交互。

除非您有理由使用网络服务，否则我不会。

Answer 7

您是否听说过服务层？我认为您可以为事务和操作使用服务层，并且使用Facade层可以帮助您在访问Business层后直接或间接地隔离和管理从UI到数据访问层的访问。这取决于你的要求。