C# 从缓存延迟加载对象图部分的推荐模式

我在一个web应用程序后面使用memcache，以尽量减少对SQL数据库的访问。我用

SerializableAttribute

标记C#对象，将它们存储到这个缓存中。我们在应用程序中通过Ninject大量使用依赖注入

有些物体很大，我想把它们分开。但是，它们来自单个存储过程调用（即，一个存储过程调用被写入完整的对象图），我希望能够将这些对象分解，并分别从缓存中延迟加载特定的子图，而不是一次将整个对象图加载到内存中

---

有哪些模式可以帮助我实现这一点？

就模式而言，我认为从单个存储过程构建的一个大型复杂对象是可疑的。我不确定您的缓存是一项要求，还是只是其实现的当前状态

我习惯的模式是一种存储库模式，使用填充特定契约的操作。这些操作包含一个或多个数据源，这些数据源调用数据库中的存储过程，这些存储过程将用于构建您提到的其中一个子图。话虽如此，如果您要从数据库延迟加载数据，那么我只能假设很多对象成员没有被使用太多时间，这进一步加深了我的观点——分解该对象

关于它有几点：

• 如果整个对象被经常使用，它可能会很健谈
• 它是通过操作完全可注射的
• 数据源包含特定对象的读取器，因此只执行一个任务（实心）
• 可以修改为使用实体框架，无需太多麻烦
• 可以设计为实现接口，使其更易于重用
• 这将要求你将这个过程分解成更小的、可咀嚼的部分，这可能只会在长期对你有利
• 如果只使用该图的一部分，那么该图中显示的复杂对象实际上不应该存在。相反，考虑分离这些对象。但是，这实际上取决于如何使用此对象

更新：

使用您的缓存作为存储库，我可能会这样处理它：

---

因此，基本上，您存储的是遗留对象，但在您的操作中，您使用它们来构建更多的相关DTO，这些DTO将返回到客户端。

我知道NHibernate会用代理对象替换对象。然后在代理对象中有某种检查，它会在您第一次尝试访问该对象时导致加载真实对象

我不确定是否有任何设计模式可以涵盖这一点，但您可以查看Nhibernate源代码

---

使用代理对象的一个缺点是，您必须小心继承和类型检查，因为您可能检查的是代理的类型，而不是实际的对象。

“[T]从单个存储过程构建的一个大型复杂对象是可疑的。”您完全正确；然而，这对我来说是一个设计限制。我不能改变这一点。我总是先和Martin Fowler核实一下：所以我想我的问题之一是，为什么这个对象这么大——或者更确切地说，它是如何被使用的，以至于你不能仅仅发回完全加载的对象？它是通过服务或其他方式返回的吗？如果是这样的话，那么我认为你需要更恰当地分离这些合同，这听起来似乎需要一些相当大的重构。如果我理解正确的话，我相信你可以用我们的library Patterns.NET@www.nubilosoft.com来做这件事。这听起来就像做Lazy.Create（..）一样简单，它基本上是在对象周围包装一个惰性加载包装器。也不确定它是否适用于这里，但我还要看一下Flyweight。@Sin美学：在这种情况下，存储过程调用的大粒度问题反映了设计糟糕的旧模式，其修改超出了范围。这个/这些对象最终是如何使用的？他们是否被管道输送出服务？我这样问是因为我的意思是，如果对象已经从数据库中取出并构建，然后缓存它，那么。。。它已经存在了，所以我不确定我是否看到了尝试“延迟加载”内存中已经存在的东西的好处？？