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

本文关键字：持久性自己的处理对象支持 | 更新日期: 2023-09-27 18:09:55

我正在寻找使用隔离存储的Windows Phone持久建模的不同选项。我提出的一个想法是，让每个对象处理自己的持久性(当然这是有意义的)，而不是为了保存对象而创建一个存储库或其他类似的实体。

我似乎找不到任何关于这种持久性方法的有用信息，这使我相信我可能无意中发现了某种反模式。

有人以这种方式处理持久性吗?如果是这样，你对这种方法的支持或反对是什么?

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

在软件开发中有几个不可否认的事实:

还有更多(:))，但这些已经足够回答你的问题了:

使用一个存储库，这样你的对象就可以被测试，对持久化一无所知，你可以交换数据存储(甚至通过网络!)不妨提前做好准备。

听起来你在谈论活动记录模式?对于一些人来说，它是有效的，但也有一些批评(主要是从可测试性/关注点分离的角度)。

最大的问题是，您最终将持久化逻辑分散在所有类中。这可能很快导致膨胀，并且还会在整个代码库中嵌入关于持久化技术的假设。如果您需要更改存储对象的位置或方式，则会变得混乱。

这些假设也使自动化测试变得更加困难，因为现在您有一个持久化层依赖关系需要处理。你可以在对象中注入一个储存库来抵消这些东西，但你还是实现了一个储存库。:)如果可以的话，最好让核心类完全忽略持久性…

好的一面是，这是一种更简单的模式，便于人们掌握，并且是在轻量级项目中快速完成任务的一种方法。如果类的数量很少，它可能是从A到b的最快方式。我仍然发现自己在小项目中构建单独的存储库，但是，我就是不能忍受将持久性的东西与我的业务逻辑混合在一起。

Cons:

优点:

基本上，如果你的数据模型是平坦和简单的，并且你的应用程序的需求是适度的，活动记录可能是一个很好的选择;然而，当您的映射需求变得更复杂时，它就开始失效了。更健壮的ORM模式(如Data Mapper)适用于这种情况。

优点

这基本上可以归结为测试变得更加困难，并且减少了在项目中进行主要重构之前的时间。

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

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

它公然反对使用数据访问层…这并没有什么不对。