设计数据访问层
我面临着有关如何设计 DAL 的设计问题。 众所周知，在其最基本的定义中，DAL 表示层 负责与某些数据存储库通信（当然我不是在谈论存储库模式）， 通常是一个数据库。现在这就是问题所在。 我们的一些业务对象必须从数据库中获取数据，而另一些则需要从其他来源（即 Web 服务）获取数据。 我们团队中的一些成员建议 BO 应该足够聪明，知道是否调用 DAL（只知道与数据库对话） 或调用所需的网络服务。其他人建议这可能不是最佳解决方案，建议所有内容都应该通过 DAL，其中它将包含每个数据检索方法的适配器或其他内容。
您将如何构建具有此类数据访问需求的系统？ 从长远来看，建议的解决方案是否足够好（第二个解决方案可能需要更多时间来开发） 或者我们是否需要采取完全不同的方法？也许有适合这种问题的设计模式......
谢谢， 阿维·希隆
I'm facing a design issue regarding how to design my DAL.
As we all know, in its most basic definition, the DAL means the layer
that is responsible for communicating with some data repository (of course I'm not talking about the Repository pattern),
usually a database. Now this is where the catch is.
Some of our business objects would have to get their data from the database, and some would get their data from other sources, i.e web services.
A few of our members on the team suggested that the BO's should be smart enough about knowing whether to call a DAL (that only knows to talk to the database)
or call the required web service. Others suggested that this might not be an optimal solution, suggesting that everything should pass through the DAL, where it would contain let's say adapters, or whatever, for each data retrieval method.
How would you architect a system with such data access needs?
Is any of the suggested solutions might be good enough for the long run (the 2nd one might take more time to develop)
or do we need to take a totally different approach? Perhaps there is a design pattern that suits this kind of issue...
Thanks,
Avi Shilon
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我强烈推荐第二种方法。业务逻辑不应该知道任何有关数据源的信息。
当它不知道时，除了通常的好处（由于隔离和更简洁的设计而更容易维护）之外，您还可以灵活地（取决于您的 DAL 设计得如何）：
根据您的最低要求，检索来自不同数据源的数据
从一组优先的数据源中检索数据以实现故障转移。
例如，您可以从路透社实时报价服务获取最新的报价，但当该服务由于 WAN 问题而出现故障时，您可以求助于替代服务，或者缓存在数据库中的旧价格。
显然，数据源按照不增加质量和不降低可靠性的优先级进行排序。
从一组优先的数据源中检索数据以实现缓存
例如，从本地缓存中检索价格，如果丢失，则从本地数据库检索，如果丢失，则向供应商的服务请求。
另外，仅举一个更容易维护的具体示例，如果您的数据源从实时查询的供应商服务更改为由供应商的推送源填充的内部黄金副本数据库，您只需更改DAO 而不是众多需要数据的 BO 中的每一个。更改更容易，测试和部署更改也更安全。
I would strongly recommend the second approach. The business logic should not know anything about the source of data.
When it does not know, in addition to the usual benefits (easier maintainability due to isolation and cleaner design), you also have the flexibility (depending on how well your DAL is designed) to:
As your minimum requirement states, retrieve data from varied data sources
Retrieve data from a prioritized set of data sources to achieve fail-over.
E.g. you get the latest price quotes from Reuters real time quote service, but when that breaks down due to WAN issues, you fall back on an alternate service, or older prices cached in the database.
Obviously, the data sources are ordered in the priority of non-increasing quality and non-decreasing reliability.
Retrieve data from a prioritized set of data sources to achieve caching
E.g. retrieve a price from a local cache, if missing, retrieve from a local database, if missing, request from vendor's service.
Also, just to give a flesh-and-bone example of easier maintainability, if your data source changes from a realtime queried vendor service to in-house gold copy database populated by a push feed from the vendor, you would only need to change the DAO instead of every one of multitude of BOs that need the data. Easier to change, and way safer to test and deploy the change.