什么模式适用于封装“上下文”查询？

Question

目前，我的工作项目循环效率非常低，在很大程度上遇到了n + 1问题。 （6n + 1，我认为。）目前，许多Web服务实例化一个对象，其构造函数构建了一个ORM对象的规范表示 - 称之为Foo和FooView()。有许多地方建立了Foo的集合; Foo的每个实例都传递给FooView，并在另一个数据库中查询其（伪）外键字段以构建文本表示形式，例如，我们可以返回<fooColor>Blue</fooColor>而不是<fooColor>5</fooColor>。这些属性的集合 - 颜色，形状和其他类似的一般属性 - 相对较小，显然应该被拉入内存。

还有另一个更复杂的查询，它会导致6n + 1问题。这是一组元数据字段。每个Foo都有一个Source。每个Source可以为其Foos子集定义一个，无或多个元数据字段。应用于给定Foo的{​​{1}}的元数据字段需要空XML标记。目前，用于构建此XML的四个（！）ORM查询（！）位于Source构造函数中，这意味着它们将针对每个FooView执行。

我的目标如下：

1. 在其他任何内容之前查询常规属性，例如Foo，Color等。
2. 运行查询以生成Shapes的集合。将主键存储在列表中。
3. 使用主键列表，运行令人发指的多连接原始SQL查询以生成Foo。
4. 调用Foo.Metadata，提供FooView的集合以及包含步骤1和3中构建的项的上下文对象。Foo将使用上下文对象提供交错逻辑而不是数据库查找。

这是一种合理的做法吗？它肯定会解决生成FooView时的一些性能问题，但这个东西应该存在于哪里？我应该叫它FooView吗？ FooHelper？ FooContext？这是一种设计模式，还是我应该用它来使这更合乎逻辑？

谢谢！