我正在研究使用独立存储在 Windows Phone 中进行持久性建模的不同选项。我想出的想法之一是每个对象处理自己的（当然是有意义的）持久性的概念，而不是为了保存对象而创建存储库或其他此类实体。
我似乎找不到任何关于这种持久性方法的好信息，这让我相信我可能偶然发现了某种反模式。
有没有人以这种方式接近持久性？如果是这样，您对这种方法的支持或反对是什么。
问问题
112 次
5 回答
6
软件开发中有几个不可否认的事实：
- 原型在您知道之前就变成了产品。
- 一个以“仅用于平台-x”为目标的应用程序将很快移植到平台-y。
- 数据存储将更改。可能是#2的结果。
还有更多（:)），但这些足以回答您的问题：
使用存储库，以便可以测试您的对象，对持久性一无所知，并且您可以交换数据存储（甚至通过网络！）最好提前计划好。
于 2011-09-27T14:37:14.230 回答
3
听起来你在谈论Active Record 模式？它适用于某些人，但也有人批评它（主要是从可测试性/关注点分离的角度来看）。
最大的问题是，您最终会得到分布在所有类中的持久性逻辑。这会很快导致膨胀，而且它还会在整个代码库中嵌入关于持久性技术的假设。如果您需要更改存储对象的位置或方式，这会变得很混乱。
这些假设也使自动化测试更加困难，因为现在您需要解决持久层依赖关系。您可以将存储库注入到对象中以抵消其中的一些内容，但是无论如何您都在实现存储库。:) 如果可以的话，最好只保留核心类完全持久性无知......
从好的方面来说，它是人们掌握的更简单的模式，并且是在轻量级项目中完成工作的快速方法。如果类的数量很少，它可能是从 A 到 B 的最快方式。我仍然发现自己在小项目上构建了单独的存储库，但是我无法忍受将持久性内容与我的业务逻辑混在一起。
于 2011-09-27T14:25:36.920 回答
2
缺点：
- 违反单一职责原则 (SRP)
- 妨碍可测试性
- 将业务逻辑与数据库紧密结合
优点：
- 易于实施
基本上，如果您的数据模型扁平且简单，并且您的应用程序要求适中，那么 Active Record 可能是一个不错的选择；但是，当您的映射要求变得更复杂时，它就会开始崩溃。像 Data Mapper 这样更健壮的 ORM 模式在这些情况下变得合适。
于 2011-09-27T14:31:08.607 回答
1
优点
- 简单
缺点
- 打破关注点分离
- 业务逻辑与数据库的紧密耦合
- 使测试变得更加困难
这几乎可以归结为测试变得更加困难，并减少了您必须在项目中进行重大重构之前的时间。
归根结底，您需要权衡项目的目标和关注点，并决定是否值得失去测试/可验证性/清洁性以获得更简单的系统。
如果它是一个简单的应用程序，您可能可以放弃 DAL 层，并选择更简单的模型。虽然如果您的应用程序有很多移动部件并且相当复杂，我会避免删除 DAL，因为您希望能够很好地测试和验证您的代码。
于 2011-09-27T14:39:12.023 回答
0
它面对使用数据访问层......并不是说有什么问题。
于 2011-09-27T14:30:38.353 回答