通过MySQL创建C#复合类：应即时加载关联对象还是按需加载？

我正在探讨通过MySQL数据库程序化创建C#类的最优方案。我的应用中需创建如Student、Classroom、Room（宿舍）这类复合类，例如Student类包含Classroom和Room属性，Classroom类还关联数据库中的其他实体：

public class Student
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public Classroom Classroom { get; set; }
    public Room Room { get; set; }
}

public class Classroom
{
    public int Id { get; set; }
    public string Title { get; set; }
    public byte Level { get; set; }
    public Teacher Teacher { get; set; }
}

// 其他关联类省略

目前我创建某个类的对象时，必须同时创建其关联类的对象（有时甚至要加载数据库的一部分数据）。这种方式虽有优秀的OOP优势——比如在DataGridView中加载所有学生后，可便捷访问关联数据：

Student student = ...
string currentTeacher = student.Classroom.Teacher.LastName   // 链式访问非常方便

但我认为这种方式不够优化，想请教：

• 是直接创建所有关联类对象更合适，还是仅创建当前对象的必要数据，其余数据按需加载/创建？
• 有没有其他更优的实现方式？

1. 立即加载（Eager Loading） #

就是你现在使用的方式：加载主实体时一次性拉取所有关联数据并实例化对象。

• 优点：
  • 链式访问无阻碍，代码可读性高，无需处理加载状态
  • 若通过JOIN语句一次性获取所有关联数据，可减少数据库查询次数，降低网络IO开销
• 缺点：
  • 存在数据冗余，很多关联数据可能从未被使用，浪费内存与带宽
  • 当关联层级较深（如Student→Classroom→Teacher→Department）时，JOIN查询会变得复杂，甚至出现笛卡尔积导致数据量爆炸，性能急剧下降

2. 延迟加载（Lazy Loading） #

仅加载主实体的核心数据，关联对象在第一次被访问时才触发数据库查询并实例化。

• 实现方式：
  • 手动实现：用Lazy<T>包装关联属性，延迟初始化逻辑：

    public class Student
    {
        public int Id { get; set; }
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int ClassroomId { get; set; }
        public int RoomId { get; set; }
        
        private Lazy<Classroom> _classroom;
        public Classroom Classroom => _classroom.Value;
        
        private Lazy<Room> _room;
        public Room Room => _room.Value;
    
        public Student(IDbDataAccess dataAccess)
        {
            _classroom = new Lazy<Classroom>(() => dataAccess.GetClassroomById(ClassroomId));
            _room = new Lazy<Room>(() => dataAccess.GetRoomById(RoomId));
        }
    }
    

  • ORM自动支持：比如Entity Framework Core，将关联属性设为virtual并启用延迟加载后，框架会生成代理类自动处理懒加载逻辑
• 优点：
  • 内存占用低，仅加载当前必需的数据
  • 初始查询速度快，无需处理复杂JOIN
• 缺点：
  • 易触发N+1查询问题：比如加载100个Student，每个Student首次访问Classroom时都发起一次查询，总共产生1+100次数据库请求，性能骤降
  • 手动实现时需注意数据库连接状态，避免访问关联属性时连接已关闭

3. 显式加载（Explicit Loading） #

主实体加载时仅携带核心数据，关联数据通过手动调用方法主动加载，完全由开发者控制加载时机。

• 实现方式：

  // 先加载学生核心数据
  var student = dbDataAccess.GetStudentById(1);
  
  // 当需要使用Classroom时，手动触发加载
  student.Classroom = dbDataAccess.GetClassroomById(student.ClassroomId);
  
  // ORM中可使用Include指定加载关联：
  // var student = dbContext.Students.Where(s => s.Id == 1).Include(s => s.Classroom).First();
  

• 优点：
  • 完全掌控数据加载时机，避免不必要的查询
  • 可灵活选择加载哪些关联数据，比如只加载Student的Classroom，不加载Room
• 缺点：
  • 代码复杂度上升，需在业务逻辑中处理加载逻辑
  • 链式访问不再顺畅，必须确保关联数据已加载才能访问

4. 投影查询（Projection Queries） #

不实例化完整的实体类，而是根据当前业务需求，仅查询所需字段并映射到DTO（数据传输对象）中。

• 实现方式：

  // 例如仅需学生姓名和对应老师姓名的场景
  var studentTeacherDto = dbContext.Students
      .Join(dbContext.Classrooms, s => s.ClassroomId, c => c.Id, (s, c) => new { s, c })
      .Join(dbContext.Teachers, sc => sc.c.TeacherId, t => t.Id, (sc, t) => new StudentTeacherDto
      {
          StudentFullName = $"{sc.s.FirstName} {sc.s.LastName}",
          TeacherLastName = t.LastName
      })
      .FirstOrDefault();
  

• 优点：
  • 性能最优，仅查询和传输必要数据
  • 避免实体类复杂关联带来的问题
• 缺点：
  • 需为不同业务场景创建大量DTO类
  • 失去实体类的OOP优势，无法链式访问完整关联关系

推荐方案 #

没有绝对最优的方案，需结合业务场景选择：

• 如果绝大多数场景下都需要访问所有关联数据（比如DataGridView展示学生时必须同时显示班级、老师、宿舍信息），立即加载是合适的，但要通过JOIN语句一次性获取所有数据，避免多次查询。
• 如果关联数据访问频率低或关联层级深，延迟加载+批量预加载是更好的选择：用ORM的Include/ThenInclude批量加载常用关联数据，同时保留懒加载处理偶尔的深层访问。
• 如果业务场景多样，不同场景需要不同数据，显式加载+投影查询组合使用：核心场景用投影查询获取DTO，复杂场景用显式加载控制实体关联加载。

另外，建议使用成熟的ORM框架（如Entity Framework Core、Dapper）处理实体与数据库的映射，这些框架已封装各种加载策略，能大幅减少手动实现的工作量，同时规避常见性能问题。

内容的提问来源于stack exchange，提问作者Čeněk Ďurian