很多时候，我会有一个业务对象，它具有用户索引的属性或某些数据的一组索引。当我在表单或其他视图中显示此对象时，我需要用户全名或数据的其他一些属性。通常我会创建另一个类 myObjectView 或类似的东西。处理这种情况的最佳方法是什么？
进一步澄清：如果我有一个问题跟踪器类，并且我的问题类具有 IxCreatedByUser 作为属性和 IxAttachment 值的集合（附件记录的索引）。当我在网页上显示此内容时，我想显示 John Doe 而不是 IxCreatedByUser，并且我想在页面上显示指向附件和文件名的链接。所以通常我创建一个带有附件对象集合和 CreatedByUserFullName 属性或类似性质的新类。创建第二个类以在页面上显示数据只是感觉不对。也许我错了？
立面图案。
我认为您的方法，创建一个外观模式来抽象具有多个数据源的复杂性通常是合适的，并且将使您的代码易于理解。
应该注意创建过多的抽象层，因为间接级别会破坏使代码更易于阅读的最初尝试。特别是，如果你觉得你只是编写类来匹配你在其他地方所做的事情。例如，如果您有一个 myLoanView，则不一定需要为系统中的每个对话创建一个 myView。从代码中退后 10 步，也许制作一个可重用且直观的抽象外观，您可以在多个地方使用。
随意详细说明您的挑战的确切性质。
一个关键原则是你的每个类都应该有一个明确的目的。如果您的“业务对象”类的目的是公开与业务对象相关的相关数据，那么在该类上创建一个属性，将查找描述的请求委托给负责该查询的相关类可能是完全合理的。信息。任何特定于您的班级的格式都将在该属性中完成。
以下是一些指导方针，可帮助您决定如何处理这种（很常见，IMO）模式：
如果您只需要一个指向不经常更改的查找表的快速链接（例如，链接到州和/或国家/地区表的地址表），您可以保留查找的延迟加载的静态副本桌子。
如果你有一个非常大的类，它需要大量的连接或子查询来加载只是为了显示目的，你可能想要像上面描述的那样为显示目的创建一个“视图”或“信息”类。只需确保 XInfo 类（用于显示）加载速度明显快于 X 类（用于编辑）。在这种情况下，在数据库端使用视图可能是一个非常好的主意。