支持和反对对象处理自身持久性的原因

Question

我正在研究使用独立存储在Windows Phone中进行持久性建模的不同选项。我提出的一个想法是每个对象处理它自己的概念（当然是理所当然的）持久性，而不是为了保存对象而创建一个存储库或其他这样的实体。

我似乎无法找到关于这种持久性方法的任何好信息，这让我相信我可能偶然发现了一种反模式。

有没有人以这种方式接近坚持？如果是这样，那么你对这种方法的看法是什么，反对的是什么。

Answer 1

软件开发有几个不可否认的事实：

1. 原型在您知道之前就会成为产品。
2. 针对“仅适用于platform-x”的应用程序很快将移植到platform-y。
3. 数据存储将发生变化。可能是＃2的结果。

还有更多（:)）但这些足以回答你的问题：

使用存储库，这样您的对象就可以进行测试，对持久性一无所知，并且可以换出数据存储（甚至可以通过线路！）也可以为此预先计划。

Answer 2

听起来你在谈论Active Record pattern？它适用于一些人，但有人批评它（主要来自可测性/关注点分离的立场）。

最大的问题是你最终会在你的所有课程中分散持久性逻辑。这很快就会导致膨胀，并且它还会在您的代码库中嵌入有关持久性技术的假设。如果您需要更改存储对象的位置或方式，那就太麻烦了。

这些假设也使自动化测试更加困难，因为现在您有一个持久层依赖性可以解决。您可以在对象中注入一个存储库以抵消其中的一些内容，但无论如何您都要实现一个存储库。 :)如果可以的话，最好只保留核心类的完整性 - 无知......

从好的方面来说，这是一个让人们掌握的简单模式，是在轻量级项目上完成工作的快捷方式。如果类的数量很少，它可能是从A到B的最快方式。我仍然发现自己在小项目上构建了单独的存储库，但是，我无法忍受将持久性内容与我的业务逻辑混合在一起。 / p>

Answer 3

<强>缺点：

• 违反单一责任原则（SRP）
• 妨碍可测试性
• 将您的业务逻辑紧紧地耦合到您的数据库

<强>优点：

• 易于实施

基本上，如果您的数据模型扁平而简单，并且您的应用程序要求适中，那么Active Record可能是一个不错的选择;但是，当您的映射要求变得更复杂时，它会开始崩溃。像Data Mapper这样的更强大的ORM模式在这些情况下变得合适。

Answer 4

赞成

• 简单

缺点

• 打破关注点分离
• 业务逻辑与数据库的紧密耦合
• 使测试更加困难

这很大程度上归结为测试变得更加困难，并且在您必须在项目中执行主要重构之前减少时间。

在一天结束时，您需要权衡项目的目标和关注点，并确定测试/可验证/清除的损失是否值得获得更简单的系统。

如果它是一个简单的应用程序，你可以放弃DAL层，并选择更简单的模型。虽然如果你的应用程序有很多移动部件并且相当复杂，我会避免删除DAL，因为你希望能够很好地测试和验证你的代码。

Answer 5

面对使用数据访问层而言......它并没有出现任何问题。