很多时候，我会有一个Business对象，该对象具有用户索引的属性或者一些数据的索引集。当我以表单或者其他视图显示此对象时，我需要用户全名或者数据的其他一些属性。通常我创建另一个类myObjectView或者类似的东西。处理此案的最佳方法是什么？

为了进一步澄清：
如果我有一个课程，一个问题跟踪程序，而我的课程则将IxCreatedByUser作为属性和IxAttachment值(附件记录的索引)的集合。当我在网页上显示此文件时，我想显示John Doe而不是IxCreatedByUser，并且我想在页面上显示指向附件和文件名的链接。因此，通常我会创建一个带有附件对象集合和CreatedByUserFullName属性或者类似性质的新类。创建第二类在页面上显示数据只是感觉不对。也许我错了？

解决方案

一个关键原则是每个类都应具有定义的目的。如果"业务对象"类的目的是公开与业务对象有关的相关数据，则在该类上创建一个属性以将对描述的请求委托给负责该对象的相关类可能是完全合理的。信息。特定于类的任何格式都将在属性中完成。

外观样式。

我认为方法(创建外立面模式以抽象化具有多个数据源的复杂性)通常是适当的，这将使代码易于理解。

应该注意创建过多的抽象层，因为间接级别会破坏使代码更易于阅读的最初尝试。特别是，如果我们觉得自己只是编写类来匹配我们在其他地方所做的事情。例如，如果我们拥有myLoanView，则不一定需要为系统中的每个对话都创建一个myView。从代码中退后10步，然后创建外观，这是一种可重用和直观的抽象，可以在多个地方使用。

随时详细说明我们挑战的本质。

以下是一些指导原则，可确定如何处理这种(非常常见的IMO)模式：

• 如果我们只需要一个快速链接到查找表的快速链接(例如，链接到州和/或者国家/地区表的地址表)，则可以保留查找的静态加载静态副本桌子。
• 如果我们有一个非常大的类，仅出于显示目的而需要加载大量的联接或者子查询，则可能要像上面所述的那样为显示目的创建一个" view"或者" info"类。只要确保XInfo类(用于显示)的加载速度明显快于X类(用于编辑)的加载速度。在这种情况下，使用数据库端的视图可能是一个好主意。