模型设计的问题，讨论下下面两种设计方式

[baidu_27549073]

比如有 游戏（英雄联盟，吃鸡等），游戏场次（练习模式，对战模式等）， 游戏房间（房间1，2，3等）
是设计成下面这样，优点是可以直接存Json文件
public class 游戏
{
public int 游戏ID{get;set;}
public int 游戏Name{get;set;}
public List<游戏场次> 场次{get;set;}
}
public class 游戏场次
{
public int 场次ID{get;set;}
public int 场次Name{get;set;}
public List<游戏房间> 房间{get;set;}
}
public class 游戏房间
{
public int 房间D{get;set;}
public int 房间Name{get;set;}
}

还是这样，存数据库，我场用这种方式
public class 游戏
{
public int 游戏ID{get;set;}
public int 游戏Name{get;set;}
}
public class 游戏场次
{
public int 游戏ID{get;set;}
public int 场次ID{get;set;}
public int 场次Name{get;set;}
}
public class 游戏房间
{
public int 游戏ID{get;set;}
public int 场次ID{get;set;}
public int 房间ID{get;set;}
public int 房间Name{get;set;}
}

但是有时两种存储方式我都会碰到，但是我取名字都是取得一样的。

[以专业开发人员为伍]

内存中的模型跟数据库表模型，本来就不完全一一对应。有差别很正常。

[以专业开发人员为伍]

假设你用 MongoDB 之类的现代数据库（但是大多都不支持事务），你就会发现更像程序内存中的对象建模。而老的关系数据库系统的数据库表，则跟程序中的 Model 的差别较大。

[娃都会打酱油了]

存json你就是nosql的思路，这时候可以OO的思想存对象，存关系型数据库你就走关系型数据库思路

[以专业开发人员为伍]

通常在程序中，我们没有必要为了迎合关系数据库表的简单性而强行把 Model 设计为简单的无嵌套形式。除非是刚学编程的人。 例如一个 Model 是这样的

public class 学校成绩
{
    public string Title;
    public string 学校名;
    public int 成绩;
    public 学校成绩[ ] 分校成绩;
}

那么假设一个省重点培训学校有10个市级分校，其中有的分校还有下一层县级分校，那么我们写一个 BLL 方法

public void Update(学校成绩 x)
{
    ......
}

就把一个成绩写入数据库（许多条记录）了。这里根本不纠结什么“第二种设计方式”，程序的重点在于面向对象系统设计，而不是什么关系数据库表。

[以专业开发人员为伍]

如果满脑子纠结传统关系数据库表的对应的所谓 Model，你可以想见，在 OOPL 程序设计中也没有什么创意，也不能用到什么好的编程。因为满脑子都是最简单的二维表数据结构了。

[以专业开发人员为伍]

例如 BLL 中要读取某个场次的数据，可能我们写

游戏场次 读取游戏场次(string id, bool 是否包括房间信息 = false)
{
    .......
}

我们在参数化中表示是否需要加载嵌套的信息。或者以一个 Lazy 的属性来动态加载游戏房间信息（仅仅当实际访问时才调用加载方法）。 总之这些都是 OOPL 的。 满脑子只有关系数据库表的时候，对于现代的编程创意，想不到这些。

[baidu_27549073]

引用 6 楼 sp1234 的回复:

引用 3 楼 starfd 的回复:

我编程比较依赖于数据库，因为一直用的SqlServer数据库，确实满脑子都是SQL，一个功能我会想怎么设计业务层SqlServer性能才会比较好。比如省重点培训学校-》市级分校-》学科-》学科成绩这四个概念 当需要查询所有院校，所有学生的成绩时。用SQL就是 Select 院校ID,学科, from 学生成绩 但是用对象我就会想，如果从入口类省重点培训学校，递归去查，最后会循环查数据库，会影响性能。 现在我程序中有两种设计方式： 历史记录会使用SqlServer，EF来建表，用的简单的无嵌套形式。 有上限，不是历史记录类的表，会使用Json文件存储，使用嵌套格式对象。 我程序中的对象都是单向的（如省重点培训学校知道有多少个市级分校，但是市级分校不知道我属于哪个省重点培训学校），因为双向的容易出现死循环，而需求中有双向需求的时候就走的有点远，如我们给省重点培训学校做的系统和市级分校做的系统因为主体不同，在设计上也不同，如果使用OOPL，每个系统。 因为数据库的模型已经被抽象到没有主体的概念，可以实现基于同一个数据，通过实现不同的查询方式，来满足不同的用户。不同系统之间通过数据库来实现交互。 当然，这跟我对Sqlserver比较熟悉，而对OOPL了解比较少有一定的关系。 一直在学习OOPL，但是我做的功能大多跟数据有关，所以在很长的时间我可能都会以关系数据库表为主，学习各种数据展示、处理、存储、技术。在小范围内使用OOPL的技术。 我的理想状态是，学习OOPL，将业务层的功能抽象出来，实现多个相关项目都可以重用。学习SqlServer，建立一个通用的数据结构。 谢谢你们的回答，让我对OOPL有了更多的了解。 我还有一些很模糊的问题，也不知道如何描述，你们说了我也模模糊糊的明白了一些。 以后的一段时间，我会学习你们回答中提及的一些概念，谢谢你们的回答。