建模时如何处理模型之间的多层嵌套？
需要设计一个考试管理系统，
每次考试（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、各位在遇到类似情况的时候，一般是怎么处理呢。

谢谢各位！！
------解决方案--------------------
神级帖子..
我菜鸟.我一般是不建外键.自由些..
------解决方案--------------------
1:N的关系，需要的时候就用
至于外键，是一种约束，保证数据的一致性和完整性，数据库中可以提高查询效率。外键可以不必强制约束
------解决方案--------------------
1.如果你是EF codefirst还必须这么建，只有这么建数据库才有关系
2.如果你不是code first是自己的领域模型，这可以不必太过充血。理论上充血模型不错，只是过于复杂和臃肿。最关键的事情是建了未必能达到啥好处。因为俺们的编程语言现在只能在平面上表达关系，并不能表达双向和复杂立体关系，也不能自动映射。玩3d max滴都知道，建立一个立体模型后，你调整角度，3d max会自动根据变换映射，渲染出你当前视角的模型---但是这是3d max，不是俺们的程序语言，至少现在企业级通用语言里面还不具备表达双向从属 和 自动变换映射关系的能力

所以不必太强求逻辑完备，你只要能在你各个业务领域的视角上，把相关业务领域的那个视角片段关系搞出来就ok了，这也是没得办法的办法，逻辑呈3d网状，但俺们的语言只能2d上描述，始终差个纬度，只好在2d纬度上用各个不同视角去拼凑。

ps：逻辑完备在目前不太靠谱，同一个模型又不同视角的解释，现在无法自动映射各个视角，你就算在你现有视角上逻辑完备了，但是你换到其他视角，你还是的自己手工映射变换。所以前面那个“貌似完备的视角”在后面却显得很多余，因为无论如何你后面都存在手工映射的变换的过程，这也是为啥在后面一阵开始流行各种(DTO，VO，DO，SOP，SOA这些各种O总体上就是关心的是对象映射变换，提供特定领域功能的视图对象)的原因
------解决方案--------------------
用EF codefirst的话，一般定义成
public virtual IList<Student> StudentList {get;set;}
然后EF构建派生类去拦截这个导航属性，并且使用延迟加载机制，也就是当你去访问StudentList才会去查询，而加载Batch的时候不会加载，因此提高性能。
------解决方案--------------------
很正常啊，没什么不好的
------解决方案--------------------

引用:

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

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

引用:

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

都可以的。
------解决方案--------------------
而且这种建模也不用往数据库上去考虑
------解决方案--------------------

引用:

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

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

引用:

非常感谢！！
 你的意思是根据实际系统的需求来确定部分嵌套。
 如果需要展示上下层级关系，就在模型中定义List。
 如果没有需求，就不去定义。
 总之一切根据需求。