Architecture 设计数据访问层

我面临一个关于如何设计DAL的设计问题。 众所周知，在其最基本的定义中，DAL表示层 负责与某个数据存储库进行通信（当然，我不是说存储库模式）， 通常是一个数据库。这就是问题所在。 我们的一些业务对象将不得不从数据库中获取数据，而一些业务对象将从其他来源（即web服务）获取数据。 我们团队中的一些成员建议，BO应该足够聪明，知道是否调用DAL（只知道与数据库对话） 或者调用所需的web服务。其他人认为这可能不是一个最佳解决方案，他们认为所有内容都应该通过DAL，在DAL中，每个数据检索方法都将包含适配器或其他内容

您将如何构建具有此类数据访问需求的系统？ 从长远来看，建议的解决方案是否足够好（第二个解决方案可能需要更多的时间开发） 还是我们需要采取完全不同的方法？也许有一种设计模式适合这种问题

谢谢，

---

Avi Shilon

我强烈推荐第二种方法。业务逻辑不应该知道任何有关数据源的信息

当它不知道时，除了通常的好处（由于隔离和更清洁的设计而更易于维护）外，您还可以灵活地（取决于DAL设计的好坏）来：

• 按照您的最低要求，从各种数据源检索数据

• 从一组按优先级排列的数据源检索数据，以实现故障转移
  例如，您可以从路透社实时报价服务获得最新的报价，但如果由于广域网问题而无法获得最新的报价，您将求助于其他服务，或者数据库中缓存的较旧价格
  显然，数据源是按不增加质量和不降低可靠性的优先级排序的

• 从一组按优先级排列的数据源检索数据以实现缓存
  例如，从本地缓存检索价格，如果缺失，从本地数据库检索，如果缺失，从供应商服务请求

---

此外，仅举一个更易于维护的实际例子，如果您的数据源从实时查询的供应商服务更改为由供应商推送填充的内部gold copy数据库，您只需要更改DAO，而不需要更改需要数据的众多BO中的每一个。更容易更改，测试和部署更改更安全。

+1我自己也会写同样的答案。但可能不太清楚；-）你有一些很好的观点，其中一些我没有想到。此外，您暗示使用DAO模式我将能够实现这种灵活性。这就是你建议我在这种情况下应该实施的模式吗？（DAL尚未实施。我们还有很长的路要走，任何有用的提示都将不胜感激；）。谢谢DVK@KLE-这是我第一次被指控写得很清楚。曾经我不是在开玩笑。谢谢@Avi-如果不知道确切的领域和要求，我就不会有太多答案之外的具体提示。具体的模式实际上比数据流的高级设计更重要，这在很大程度上取决于您的数据源、它们的性能和可靠性以及应用程序的需要。