如何防止同一个业务对象有多个类？
很多时候，我会拥有一个 Business 对象，该对象具有用户索引的属性或某些数据的一组索引。 当我在表单或其他视图中显示此对象时，我需要用户的全名或数据的一些其他属性。 通常我会创建另一个类 myObjectView 或类似的类。 处理此案的最佳方法是什么？
进一步澄清： 如果我有一个问题跟踪器类，并且我的问题类具有 IxCreatedByUser 作为属性和 IxAttachment 值（附件记录的索引）的集合。 当我在网页上显示此内容时，我想显示 John Doe 而不是 IxCreatedByUser，并且我想在页面上显示附件和文件名的链接。 因此，通常我会创建一个带有 Attachment 对象集合和 CreatedByUserFullName 属性或类似性质的新类。 创建第二个类来在页面上显示数据感觉是错误的。 也许我错了？
A lot of the time I will have a Business object that has a property for a user index or a set of indexes for some data. When I display this object in a form or some other view I need the users full name or some of the other properties of the data. Usually I create another class myObjectView or something similar. What is the best way to handle this case?
To further clarify:
If I had a class an issue tracker and my class for an issue has IxCreatedByUser as a property and a collection of IxAttachment values (indexes for attachment records). When I display this on a web page I want to show John Doe instead of the IxCreatedByUser and I want to show a link to the Attachment and the file name on the page. So usually I create a new class with a Collection of Attachment objects and a CreatedByUserFullName property or something of that nature. It just feels wrong creating this second class to display data on a page. Perhaps I am wrong?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一个关键原则是每个课程都应该有明确的目的。 如果“业务对象”类的目的是公开与业务对象相关的相关数据，则在该类上创建一个属性，将查找描述的请求委托给负责该业务的相关类，这可能是完全合理的。信息。 任何特定于您的类的格式都将在该属性中完成。
One key principle is that each of your classes should have a defined purpose. If the purpose of your "Business object" class is to expose relevant data related to the business object, it may be entirely reasonable to create a property on the class that delegates the request for the lookup description to the related class that is responsible for that information. Any formatting that is specific to your class would be done in the property.
以下是一些指导原则，可帮助您决定如何处理这种（非常常见，IMO）模式：
如果您需要的只是一个指向不经常更改的查找表的快速链接（例如，链接到的地址表）州和/或国家/地区的表），您可以保留查找表的延迟加载的静态副本。
如果您有一个非常大的类，仅出于显示目的需要加载大量联接或子查询，那么您可能需要创建一个“视图”或“信息”类以用于显示目的，就像上面描述的那样。 只需确保 XInfo 类（用于显示）的加载速度明显快于 X 类（用于编辑）。 在这种情况下，在数据库端使用视图可能是一个非常好的主意。
Here's some guidelines to help you with deciding how to handle this (pretty common, IMO) pattern:
If you all you need is a quickie link to a lookup table that does not change often (e.g. a table of addresses that links to a table of states and/or countries), you can keep a lazy-loaded, static copy of the lookup table.
If you have a really big class that would take a lot of joins or subqueries to load just for display purposes, you probably want to make a "view" or "info" class for display purposes like you've described above. Just make sure the XInfo class (for displaying) loads significantly faster than the X class (for editing). This is a situation where using a view on the database side may be a very good idea.
外观模式。
我认为您创建外观模式来抽象多个数据源的复杂性的方法通常是合适的，并且将使您的代码易于理解。
应注意创建过多的抽象层，因为间接级别会破坏使代码更易于阅读的最初尝试。 特别是，如果您觉得自己编写的课程只是为了与您在其他地方所做的事情相匹配。 例如，如果您有一个 myLoanView，则不一定需要为系统中的每个对话创建一个 myView。 从代码中退后 10 步，也许可以创建一个可重用且直观的抽象外观，您可以在多个地方使用。
请随意详细说明您面临的挑战的确切性质。
The façade pattern.
I think your approach, creating a façade pattern to abstract the complexities with multiple datasources is often appropriate, and will make your code easy to understand.
Care should be taken to create too many layers of abstractions, because the level of indirection will ruin the initial attempt at making the code easier to read. Especially, if you feel you just write classes to match what you've done in other places. For intance if you have a myLoanView, doesn't necessarily you need to create a myView for every single dialogue in the system. Take 10-steps back from the code, and maybe make a façade which is a reusable and intuitive abstraction, you can use in several places.
Feel free to elaborate on the exact nature of your challenge.