3

我们正在开发一个“中间层”来替换现有的业务逻辑/数据访问层。我们面临的一个设计问题是，我们需要以允许多个客户的数据库和/或中间层部分作为我们托管产品的一部分存在于同一服务器上的方式来设计它。托管环境的数据库模式和设置此时已完全确定，因为它已经投入生产。本质上，在托管环境中的给定数据库服务器上，每个客户都有一个使用其唯一客户 ID 命名的 SQL Server 实例。

我们试图决定的是，是从客户端应用程序一直到 Web 服务、业务逻辑和对每个客户的数据库的数据访问都有一条单独的路径，还是每个部分都有一个单独的共享实例，其中数据访问层负责从正确的 SQL Server 实例或两者之间的某个地方获取数据。对于所有东西都有一个共享路径，如果任何一个部分发生故障，所有访问它的客户端都将死在水中。另一方面，对于每个客户都有单独的路径，除了可能过于复杂之外，还有（似乎）需要维护的更多内容？这是我们正在考虑的两个选项的可怕 ASCII 艺术图片：

[Client]--|                                                             |--[DB]
[Client]--|                                                             |--[DB]
          |--> [Web Service] --> [Business Logic] --> [Data Access] ----|
[Client]--|                                                             |--[DB]
[Client]--|                                                             |--[DB]

或这个：

[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB]

其中哪一个（或中间选项）会更好，为什么？

4

1 回答 1

2

这是一个相当笼统的问题，所以我将给出一个相当笼统的答案。我过去根据类似的原则构建了平台，我能给你的唯一建议是仔细考虑将架构分为两层：

  • 一个完全通用的框架，可以处理所有常见的通用操作
  • 一个可定制的“客户”特定层，您可以在其中包含任何不寻常的客户特定功能。

也许您的许多客户可以单独在通用框架上操作，这很好，但是当客户愿意为一些定制支付您的费用时，您可以通过扩展而不是修改通用层来适应他们。

一般来说，我们通过非常标准的技术处理这种可扩展性和泛型与专用行为的耦合——每个客户的配置文件定义他们的处理“管道”、客户程序集的动态加载、大量使用接口、允许通用组件委托操作到运行时的标准实现或客户特定的实现，等等。

希望有帮助。

于 2011-02-16T21:57:18.183 回答