在类内部添加其他的类作为属性是否合理？

Question

现在需要定义一个类Consume，用于操作消费记录，其中需要使用客户和分店的部分信息，所以在里面加一个User类型，一个Shop类型的属性，
这种方式是否是良好的设计？因为从数据库读取数据的时候只会初始化User的部分字段，可能会导致User的部分方法失效。
public class Consume
    {
        /// <summary>
        /// 消费单据编号    
        /// </summary>
        public string ConsumeID { get; set; }             /// <summary>
        /// 店号 
        /// </summary>
        public Shop ShopItem { get; set; }                 /// <summary>
        /// 消费日期          
        /// 由存储过程生成
        /// </summary>
        public DateTime Date { get; set; }       
 
        /// <summary>
        /// 单据类型
        /// </summary>
        public string DocumentType { get; set; }     
 
        /// <summary>
        /// 客户 
        /// </summary>
        public User ConsumeUser { get; set; }        
}

Answer 1

你分清楚，你到底在写C#对象，还是在写sql数据库表

Answer 2

类的定义没有问题。问题在于“从数据库读取数据的时候只会初始化User的部分字段 ”，不要把面向sql编程的思维跟面向对象的思维混在一起。

Answer 3

并没什么合不合适。
你这个是db first思想。
现在提倡code first思想。

Answer 4

没问题啊，可以在Consume初始化方法中实例化ConsumeUser，防止直接使用ConsumeUser的属性时造成空指针；

Answer 5

目前是简化了这个类的设计，因为user类中的很多属性可以直接使用了，但是担心在开发后期产生目前无法预期的问题。所有来问一下有丰富经验的各位。

Answer 6

设计 class 或者 interface 还纠结数据库表啊？顶多是偶尔考虑一下而已，并不会纠结于它。否则，可见你的 class 和 interface 没啥业务领域建模的真东西。

Answer 7

这就好像是给用户设计软件，比如说你做一个电子杂志，你说你要做 Excel 表；你做一个跨10个角色的20个节点30个分支路线的供应链流程，你说你要做一个 Excel；你做一个几十个子公司的集团绩效管理，你说你做一个 Excel 表...........满脑子只有简单二维表的增删改查，忘记了用户领域的表单和流程有几万需求点需要创意设计。设计 calss、interface，软件面向对象分析和设计模型，UML 各种模型等等，都是从用户交互操作的反反复复的个性化的“设计”出发来设计数据结构的，不是像刚学编程整天在电脑前敲代码的学生那样满脑子只有数据库表的。

Answer 8

这可能说到点子上了。
其实所谓“领域建模”我到现在都还没领会如何应用好。
在我的判断里，总感觉这反而会使代码不够简洁。也很有可能我是从数据库编程时代过来的人，觉得类似sql的语法是更简洁，更能体现业务逻辑的，我需要条理清晰的“知道”具体的业务逻辑，而不是“领域设计”层的整体逻辑，偏好这个。其实说到“脱离数据库进行对象设计”，EF是很好的例证。对于对象包含（即多表关联），它是通过“导航属性”实现的。所以EF应该是包含了“领域设计”概念的，也就是你现在考虑的这种设计模式。
那么有了导航属性，如果不能很好的支持它，是会造成开发效率下降的，所以EF对导航属性有很好的支持。你能通过它提供的一些方法，较好
的填充相关数据，更新相关表。所以可以说“EF较好的支持了领域设计”，是可以作为你探索的方向的。但对于我自己来说，我是在精读了《Entity Framework 6 Recipes 2nd Edition》之后，觉得不喜欢它这种实现，因为它：
1、仍有缺陷
2、对于不精通EF的程序员，用的不好的话，会降低访问数据库的性能（EF智能生成的sql不够好）
所以我抛弃了EF的导航属性，我直接用LINQ写多表关联，自己来把握SQL语句的性能。所以我仍然坚持我的观点，这也可以理解为一种设计偏好。再讲远一点，EF的导航属性设计的有点啰嗦和缺陷，其实还是因为它映射的是关系型数据库。如果你用的是非关系型数据库，比如NoSQL的话，那就可以实现完全的对象化设计或者说“领域设计”，因为它的存储就是完全按你对象设计来的。