建模时如何处理模型之间的多层嵌套？

Question

需要设计一个考试管理系统，
每次考试（Exam）都有很多考点（Site），一个考点会有多个科目（Subject），每个科目有多个考场（Room），每个考场有多个批次（Batch），每个批次都有很多学生（Student）。
分别给每个模型建模（英文名）。
为了方便，在Batch中定义Student泛型列表，如下：public class Batch
{
    public string Num {get;set;}
    public string Name {get;set;}    public List<Student> StudentList {get;set;}
}以此类推，在Room中定义Batch列表，在Subject中定义Room列表，在Site中定义科目列表，直至Exam中定义Site列表。两个问题：
1、这样建模，有没有什么问题，会不会影响系统的运行效率。
2、各位在遇到类似情况的时候，一般是怎么处理呢。谢谢各位！！模型

Answer 1

1.如果你是EF codefirst还必须这么建，只有这么建数据库才有关系
2.如果你不是code first是自己的领域模型，这可以不必太过充血。理论上充血模型不错，只是过于复杂和臃肿。最关键的事情是建了未必能达到啥好处。因为俺们的编程语言现在只能在平面上表达关系，并不能表达双向和复杂立体关系，也不能自动映射。玩3d max滴都知道，建立一个立体模型后，你调整角度，3d max会自动根据变换映射，渲染出你当前视角的模型---但是这是3d max，不是俺们的程序语言，至少现在企业级通用语言里面还不具备表达双向从属 和 自动变换映射关系的能力所以不必太强求逻辑完备，你只要能在你各个业务领域的视角上，把相关业务领域的那个视角片段关系搞出来就ok了，这也是没得办法的办法，逻辑呈3d网状，但俺们的语言只能2d上描述，始终差个纬度，只好在2d纬度上用各个不同视角去拼凑。ps：逻辑完备在目前不太靠谱，同一个模型又不同视角的解释，现在无法自动映射各个视角，你就算在你现有视角上逻辑完备了，但是你换到其他视角，你还是的自己手工映射变换。所以前面那个“貌似完备的视角”在后面却显得很多余，因为无论如何你后面都存在手工映射的变换的过程，这也是为啥在后面一阵开始流行各种(DTO，VO，DO，SOP，SOA这些各种O总体上就是关心的是对象映射变换，提供特定领域功能的视图对象)的原因

Answer 2

非常感谢！！
你的意思是根据实际系统的需求来确定部分嵌套。
如果需要展示上下层级关系，就在模型中定义List。
如果没有需求，就不去定义。
总之一切根据需求。那么如果我只是定义，不在程序中去调用，应该不会影响系统效率吧。

Answer 3

用EF codefirst的话，一般定义成
public virtual IList<Student> StudentList {get;set;}
然后EF构建派生类去拦截这个导航属性，并且使用延迟加载机制，也就是当你去访问StudentList才会去查询，而加载Batch的时候不会加载，因此提高性能。

Answer 4

不是用ICollection么？IList是有Insert的方法的，在数据库里如何呈现？

Answer 5

不是，我的意思是，IList的Insert、RemoveAt等根据Index的方法貌似是没有用的。可以说是多余的。在Key是Guid的时候，这个数据库排序是混乱的吧？新增的数据不一定是在最后一个

Answer 6

实际上所谓“建模”这个词儿，就好像有些人以为编程不过是“增删改查而已”一样，容易被人理解为静态的东西。这种僵化了的东西应该放在哪层呢？应该如何与其它层面通讯呢？这才是应该考虑的。表现层一般来说不对领域再去进行什么单独“建模”，而是使用业务逻辑层给它提供的实体模型和服务接口。如果你搞清楚自己的这个Batch是否适合用于通讯，此时你就清楚该不该删除这个 StudentList 了。

Answer 7

本人菜鸟一枚，绝无炫技之意。呵呵。
我的本意是想问：我在建模时这样编码，程序中有的功能部分可能会用到其中List，有的功能呢部分不会用到。
在程序代码没有访问其中List的时候，系统效率应该不受影响吧。