将业务对象中的数据访问代码解耦并不是什么新鲜事，但我总是在寻找实现目标的“最佳方式”。
我有以下课程：
橙色 - 这是我的商业对象。
OrangeList - 这是一个橘子列表。
用户可以通过调用OrangeList.Fetch（someCriteria）从数据存储中获取Orange对象。因此，OrangeList必须引用数据访问层 - 因此它具有以下属性：IDataProvider MyDataProvider。
这对我有用，但问题是我们不能单独取一个Orange - 我们总是要通过OrangeList。
Orange和OrangeList中的任何一个或两者都必须从一个容纳DataProvider的常见对象下降。
这是一个问题，还是我的方法首先是偏离标记？
感谢任何提示/指示。
编辑：根据下面的讨论，我查看了存储库模式。
但是对于我的项目，我认为将存储库与DAL进一步分离是一个好主意。
所以....存储库是我如何获取橘子，并保存橘子，但仍然不知道如何。我将它委托给IDataProvider，它可能是图中列出的一些。
澄清一下 - Orange不知道如何获取/更新自己，对吧？这是一个纯粹的业务对象 - 这是重点吗？
alt text http://img22.imageshack.us/img22/2460/repositorya.jpg
如果你想知道，我的“LegacyDataProvider”是支持一个OLD系统，它访问一个基于文件的数据库（FoxPro，eek） - 但是这让我把它包起来并保持与我的距离新代码。
就.NET程序集构造而言，为了防止循环引用，看起来我将拥有Repository.DLL [OrangeRepo]，DataProviderInterface.DLL [IDataProvider]和BusinessObjects.dll [Orange]。一切都好吗？
我是否了解了存储库？
答案 0 :(得分：2)
答案 1 :(得分：1)
我会（并且确实）从主API对象（OrangeCart？）中组合出所有这些东西，它也构成了数据访问层的接口对象。您的Oranges和OrangeLists知道他们属于OrangeCart，并与DAL操作进行对话。
答案 2 :(得分：0)
我没有OrangeList（someCriteria），而是Oranges.Criteria1List，Oranges.Criteria2List。对于单身人士，我会有Oranges.GetItem（orangeId）。
按照自己的方式行事，BusinessObject最终需要考虑逻辑数据设计术语而不是概念术语。
（存储库实现让我感到同样的不适 - 通常他们所使用的只是在表上放置一个薄抽象的厚代码层。我不喜欢BL需要知道数据库的实现细节类似于数据类型和大小。通常，解耦这些类型的依赖关系很有用。）
