data-access-layer - 从业务对象中抽象出数据访问层

Question

将数据访问代码与业务对象分离并不是什么新鲜事，但我一直在寻找实现某些目标的“最佳方式”。

我有以下课程：

橙色 - 这是我的业务对象。

OrangeList - 这是一个橘子列表。

用户将通过调用 OrangeList.Fetch(someCriteria) 从数据存储中获取 Orange 对象。因此，OrangeList 必须具有对数据访问层的引用 - 所以它具有属性：IDataProvider MyDataProvider。

这对我有用，但问题是我们不能单独获取一个橙色 - 我们总是必须通过 OrangeList。

Orange 和 OrangeList 中的任何一个或两者都必须来自一些持有 DataProvider 的公共对象。

这是一个问题，还是我的方法一开始就离题了？

任何提示/指针表示赞赏，谢谢。

编辑：根据下面的讨论，我检查了存储库模式。

但是对于我的项目，我认为将存储库与 DAL 进一步分开是个好主意。

所以....存储库是我获取橘子和保存橘子的方式，但仍然不知道如何。我将它委托给 IDataProvider，它可能是图中列出的一些。

澄清一下 - Orange 不知道如何获取/更新自己，对吧？这是一个纯粹的业务对象——这就是重点吗？

如果你想知道，我的“LegacyDataProvider”是为了支持一个旧系统，它访问一个基于文件的数据库（FoxPro，eek）——但这让我可以把它包装起来，让它远离我的新代码。

在 .NET 程序集构造方面，为了防止循环引用，看起来我将拥有一个 Repository.DLL [OrangeRepo]、一个 DataProviderInterface.DLL [IDataProvider] 和一个 BusinessObjects.dll [Orange]。都好？

那我有没有关于存储库的想法？

score 2 · Accepted Answer

2

于 2009-04-10T22:40:27.490 回答

score 1 · Accepted Answer

我会（并且确实）从一个主 API 对象（OrangeCart？）中组合所有这些东西，该对象也构成数据访问层的接口对象。您的 Oranges 和 OrangeLists 知道它们属于 OrangeCart 并与它对话以进行 DAL 操作。

score 0 · Accepted Answer

而不是 OrangeList(someCriteria)，我有 Oranges.Criteria1List、Oranges.Criteria2List。对于单身人士，我有 Oranges.GetItem(orangeId)。

按照自己的方式进行操作，BusinessObject 最终需要从逻辑数据设计术语而不是概念术语中进行思考。

（存储库实现给我带来了同样的不适——它们通常只是在表上放置一个薄抽象厚代码层。我不希望 BL 被要求了解数据库实现细节，如数据类型和大小。解耦这些依赖关系通常很有用。）

3 回答 3