不同用例配不同延迟加载策略，但级别不宜过多

现实中经常出现这种情况：不同的用例对同一个对象图，实际需要的子集完全不同——有的用例只需要对象图的这一小部分，有的用例需要另一部分，为了达到最佳效率，应该为每个具体用例定制加载”恰到好处”的那部分子图，而不是用一套固定策略应付所有场景。解决这个问题的思路是为不同用例配备独立的数据库交互对象：如果用的是数据映射器，可以准备两个订单映射器——一个直接把订单项一起加载出来，另一个则对订单项做延迟加载，应用代码按当前用例选用合适的映射器；这个思路的一个变体是共用同一套基础加载方法，但通过不同的策略对象来决定具体的加载模式，实现上更复杂，但是一种更彻底的行为分解方式。不过，这种”按用例定制加载策略”的思路不该无限细分下去：理论上似乎可以设计出一整套精细分级、深浅不一的延迟加载对象，但作者的实际经验是真正用得上的往往只有两级——一级是完全加载，另一级是仅用于列表展示识别的轻量加载；再往下增加更多延迟级别，只会平添复杂度，却换不来相应的收益。可迁移启发：”按不同使用场景定制资源加载深度”是一个值得追求的优化方向，但优化的粒度应该由实际用例的真实差异决定，而不是理论上能拆多细就拆多细——多数场景两三档粒度就足够覆盖实际需求，继续精细化往往是过度设计。