关于List的类属性 请求ߝ 类设计困境
当我需要从表(数据库)中获取多条记录时,我的方法会填充特定类的列表(我的所有数据访问层方法都使用列表来进行基于集合的选择语句。我不使用数据表/数据集或 xmlDocument 方法) 。 让我们假设下一个简化的场景; 我有两个类 – 具有这些字段/属性的客户和订单:
Class Customer{
int IDCustomer
string CustomerName
string CustomerAddress
string CustomerCity
}
Class Order{
int IDOrder
int IDCustomer
string SalePersonName
decimal OrderSubTotal
datetime OrderDateCreated
}
因此,假设我们需要一个方法将所有数据传递到 UI (ObjectDataSource) 订单类属性 + CustomerName 和 CustomerCity 来自 Customer 类。 我希望 Order 类中的方法看起来像:
public List<Order> SelectAll(){
}
那么我应该使用哪种方法来完成此任务? 如何设置订单类,使其包含两个与最佳实践、面向对象范例、性能等相关的额外属性(CustomerName 和 CustomerCity):
APROACH A:
Class Order{
int IDOrder
int IDCustomer
string SalePersonName
decimal OrderSubTotal
datetime OrderDateCreated
//--- plus two extra properties of type string
string CustomerName
string CustomerCity
}
APROACH B:
Class Order{
int IDOrder
int IDCustomer
string SalePersonName
decimal OrderSubTotal
datetime OrderDateCreated
//--- plus extra property of type Customer
Customer _Customer
}
APROACH C:
???
我使用的是.NET 2.0。
When I need to grab more than one record from table(database), my method populates List of particular class (all of my data access layer methods use List for set based select statements. I Don't use datatable/dataset or xmlDocument approach). So lets suppose next simplified scenario; I have two classes – customer and order with these fields/properties:
Class Customer{
int IDCustomer
string CustomerName
string CustomerAddress
string CustomerCity
}
Class Order{
int IDOrder
int IDCustomer
string SalePersonName
decimal OrderSubTotal
datetime OrderDateCreated
}
So, lets say that we need a method which deliver to the UI (ObjectDataSource) all data from
Order Class properties + CustomerName and CustomerCity from Customer class.
I want my method from Order class looks like:
public List<Order> SelectAll(){
}
so which approach should I use to accomplish this? How to setup Order Class so it contain that two extra properties (CustomerName and CustomerCity) concerning best practices, object oriented paradigm, performance etc. :
APROACH A:
Class Order{
int IDOrder
int IDCustomer
string SalePersonName
decimal OrderSubTotal
datetime OrderDateCreated
//--- plus two extra properties of type string
string CustomerName
string CustomerCity
}
APROACH B:
Class Order{
int IDOrder
int IDCustomer
string SalePersonName
decimal OrderSubTotal
datetime OrderDateCreated
//--- plus extra property of type Customer
Customer _Customer
}
APROACH C:
???
I am on .NET 2.0.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
我可以毫无问题地创建另一个类来展平充当视图模型的查询。
I have no problem creating another class that flattens the query whichs acts as a viewmodel.
这听起来像是 ORM 的工作。
This sounds like a job for an ORM.
毫无疑问,B。客户和订单之间存在一对多关系 - 一个客户有多个订单(订单列表),一个订单有一个客户(客户类型的标量属性)。
对于用户界面,您可以创建一个单独的类来包装订单,如下所示。
No question, B. There is a one-to-many relationship between customers and orders - a customer has many orders (list of orders) and an order has one customer (scalar property of type customer).
For the user interface you can then create a separate class that wraps an order like the following.
如果您允许存在一对多的客户与订单关系,则后面会出现一个具有订单列表的客户类。 虽然这与您最初的请求略有不同,但您可能会更轻松地操纵客户及其包含的订单,而不是复制父级的成员。
If you allow that a one-to-many customer to order relationship exists, a customer class that has-a list of orders follows. While this slightly deviates from your original request, you'll probably have an easier time of manipulating a customer and the orders it contains rather than duplicating members from the parent.
因为这是一个设计问题,我认为需要更多信息才能给出完整的答案,因为我认为这取决于具体情况。
如果您已经加载了 Order 对象和 Customer 对象,并将它们用于表示层中的不同用途,那么创建一个专门的类来展平显示数据是一个很好的解决方案。
如果您正在加载信息以显示订单列表,并且需要每个订单的客户信息,那么我不得不问为什么您不直接创建一个包含相关字段的 CustomerOrder 类,然后加载它来开始因为无论如何您都不会使用客户的额外数据。
所有这些设计决策都取决于外部因素。 最后,我想说,正确的设计决策通常是满足您需求的最简单的决策。
Because this is a design question I think that there is more information needed to give a complete answer because I think that it depends on the circumstances.
If you already have the Order objects and the Customer objects loaded and use them for different things in the presentation layer then creating a specialized class to flatten the display data is a good solution.
If you are loading the information to display a list of orders and need the customer information on each order, then I would have to ask why you don't just create a CustomerOrder class that has the relevant fields on it and just load that to begin with because you are not going to use the extra data of Customer anyway.
All these design decisions depend on external factors. In the end, I would say that the right design decision is usually the simplest one that meets your needs.