13,190
社区成员
发帖
与我相关
我的任务
分享关于继承对象的持久化
小弟从事.net1年多了，一直有以下疑惑，请高手指点迷津。
举例：
最初设计在业务逻辑层有如下三个类Person,Student,Teacher. Person是抽象基类，Student,Teacher是继承子类,这样建立类符合oo思想，扩展性等方面有很多好处。但是DAL层如何持久化数据，小弟遇到了麻烦。
1.每个子类建立一个表(Student,Teacher2个表).（感觉有太多冗余数据，不符合数据库设计规范）。
2.子类的所有属性(剔除相同的属性)建立一个表(Person),表中加上一个标志字段标明是Student,还是Teacher.
小弟是想按第2种思路处理，但没有实际实施，遇到了很多困难（orm等方面知识很欠缺）。
无奈最后是按照PetShop3的那种模式处理的，一个业务对象对应数据库的一个表， 业务逻辑层也被修改了。只有一个Person类（去掉了Student,Teacher类，加上了标识子类的属性）。
小弟要是想按照最初的业务逻辑层三个类Person,Student,Teacher来处理，应该如何持久化数据？或者告知相关的资料。问题很简单，高手见谅。
举例：
最初设计在业务逻辑层有如下三个类Person,Student,Teacher. Person是抽象基类，Student,Teacher是继承子类,这样建立类符合oo思想，扩展性等方面有很多好处。但是DAL层如何持久化数据，小弟遇到了麻烦。
1.每个子类建立一个表(Student,Teacher2个表).（感觉有太多冗余数据，不符合数据库设计规范）。
2.子类的所有属性(剔除相同的属性)建立一个表(Person),表中加上一个标志字段标明是Student,还是Teacher.
小弟是想按第2种思路处理，但没有实际实施，遇到了很多困难（orm等方面知识很欠缺）。
无奈最后是按照PetShop3的那种模式处理的，一个业务对象对应数据库的一个表， 业务逻辑层也被修改了。只有一个Person类（去掉了Student,Teacher类，加上了标识子类的属性）。
小弟要是想按照最初的业务逻辑层三个类Person,Student,Teacher来处理，应该如何持久化数据？或者告知相关的资料。问题很简单，高手见谅。
...全文
请发表友善的回复…
发表回复
ahbool123 2009-01-07
- 打赏
- 举报
[Quote=引用 2 楼 caicai_45 的回复:]
随便瞎说下，不必当真
Person其实可以不做为抽象类的，这个是因为面向对象和关系型数据库的矛盾导致。
如果是个抽象类，是不能被实例化的，必然导致没办法把这个对象的数据存储到数据库中。
其实可以采用这样的方式去做， 组合。 Person不是抽象类。Person中有公共的字段。
Teacher，Student 中包含Person。 这样重复的字段就不会出现在Teacher，Student中，他们中只有自己特殊的字段。
在数据库的设计中，这…
[/Quote]
这样扩展性好
随便瞎说下，不必当真
Person其实可以不做为抽象类的，这个是因为面向对象和关系型数据库的矛盾导致。
如果是个抽象类，是不能被实例化的，必然导致没办法把这个对象的数据存储到数据库中。
其实可以采用这样的方式去做， 组合。 Person不是抽象类。Person中有公共的字段。
Teacher，Student 中包含Person。 这样重复的字段就不会出现在Teacher，Student中，他们中只有自己特殊的字段。
在数据库的设计中，这…
[/Quote]
这样扩展性好
caicai_45 2009-01-07
- 打赏
- 举报
目前的较为通用的有Nhibernate。vs2008里面的实体框架，目前来看，好像还不是特别成熟（其实是我没怎么用 ^_^）
abcyzq 2009-01-07
- 打赏
- 举报
To 5楼
您前面2点说的我都明白，我就是对第三点的解决方案了解太少，而产生担心。
您第三点中提到的成熟的orm框架可以解决，可以推荐一个简单易用的么
您前面2点说的我都明白，我就是对第三点的解决方案了解太少，而产生担心。
您第三点中提到的成熟的orm框架可以解决，可以推荐一个简单易用的么
caicai_45 2009-01-07
- 打赏
- 举报
呵呵，其实你看怎么看待这个工作量了。
一 面向对象的合理性
一股脑把所有字段都增加到Person里面，这样本来其实就不是合理的做法。
你可以这样来分析， 是不是每个Person都需要一个学号（这个是学生必须要的，但是老师不要），
虽然你不要的地方可以置为null值。
但是就合理性来说，不是我的属性，我干吗要啊？
二 应对变化
当有一天，又增加一个校长这样的继承于Person的对象，你又在Person里面增加一堆校长的特有字段？
将不是校长的这些数据，对应的校长字段，全部置为null？
然后仔细检查下Student和Teacher的实例化的方式，有没有出错的地方。
还是增加一张校长的表，包含Person，对学生和老师没有任何影响来的好？
对扩展开发，对修改封闭。
三 工作量
目前的成熟一点的orm框架，在做持久层的时候，这样的组合关系，基本上可以做到一次性存储。
Student.Save();
如果里面修改了一些Person的属性，可以一并保存到数据库中，不需要你担心过多。
这个工作量增加在哪？
一 面向对象的合理性
一股脑把所有字段都增加到Person里面，这样本来其实就不是合理的做法。
你可以这样来分析， 是不是每个Person都需要一个学号（这个是学生必须要的，但是老师不要），
虽然你不要的地方可以置为null值。
但是就合理性来说，不是我的属性，我干吗要啊？
二 应对变化
当有一天，又增加一个校长这样的继承于Person的对象，你又在Person里面增加一堆校长的特有字段？
将不是校长的这些数据，对应的校长字段，全部置为null？
然后仔细检查下Student和Teacher的实例化的方式，有没有出错的地方。
还是增加一张校长的表，包含Person，对学生和老师没有任何影响来的好？
对扩展开发，对修改封闭。
三 工作量
目前的成熟一点的orm框架，在做持久层的时候，这样的组合关系，基本上可以做到一次性存储。
Student.Save();
如果里面修改了一些Person的属性，可以一并保存到数据库中，不需要你担心过多。
这个工作量增加在哪？
abcyzq 2009-01-07
- 打赏
- 举报
[Quote=引用 2 楼 caicai_45 的回复:]
随便瞎说下，不必当真
Person其实可以不做为抽象类的，这个是因为面向对象和关系型数据库的矛盾导致。
如果是个抽象类，是不能被实例化的，必然导致没办法把这个对象的数据存储到数据库中。
其实可以采用这样的方式去做， 组合。 Person不是抽象类。Person中有公共的字段。
Teacher，Student 中包含Person。 这样重复的字段就不会出现在Teacher，Student中，他们中只有自己特殊的字段。
在数据库的设计中，这…
[/Quote]
您的意思是数据库建立三张表？Person,Student,Teacher?表多了工作量会不会增加不少
随便瞎说下，不必当真
Person其实可以不做为抽象类的，这个是因为面向对象和关系型数据库的矛盾导致。
如果是个抽象类，是不能被实例化的，必然导致没办法把这个对象的数据存储到数据库中。
其实可以采用这样的方式去做， 组合。 Person不是抽象类。Person中有公共的字段。
Teacher，Student 中包含Person。 这样重复的字段就不会出现在Teacher，Student中，他们中只有自己特殊的字段。
在数据库的设计中，这…
[/Quote]
您的意思是数据库建立三张表？Person,Student,Teacher?表多了工作量会不会增加不少
xiaolei1982 2009-01-07
- 打赏
- 举报
既然这样做一个公共的person持久层，让student和teather继承不行吗？
还是不太理解你所问的
还是不太理解你所问的
caicai_45 2009-01-07
- 打赏
- 举报
随便瞎说下，不必当真
Person其实可以不做为抽象类的，这个是因为面向对象和关系型数据库的矛盾导致。
如果是个抽象类，是不能被实例化的，必然导致没办法把这个对象的数据存储到数据库中。
其实可以采用这样的方式去做， 组合。 Person不是抽象类。Person中有公共的字段。
Teacher，Student 中包含Person。 这样重复的字段就不会出现在Teacher，Student中，他们中只有自己特殊的字段。
在数据库的设计中，这两张表会有一个PersonID的外键关系，关系是一对一的。
这样基本能满足降低重复性，也能满足对象的持久化。但是确不是一个继承关系，而是一个组合关系了。感觉上不对味了，但是没有十全十美的方案，对不？
Person其实可以不做为抽象类的，这个是因为面向对象和关系型数据库的矛盾导致。
如果是个抽象类，是不能被实例化的，必然导致没办法把这个对象的数据存储到数据库中。
其实可以采用这样的方式去做， 组合。 Person不是抽象类。Person中有公共的字段。
Teacher，Student 中包含Person。 这样重复的字段就不会出现在Teacher，Student中，他们中只有自己特殊的字段。
在数据库的设计中，这两张表会有一个PersonID的外键关系，关系是一对一的。
这样基本能满足降低重复性，也能满足对象的持久化。但是确不是一个继承关系，而是一个组合关系了。感觉上不对味了，但是没有十全十美的方案，对不？
leonwan 2009-01-07
- 打赏
- 举报
支持
glt3260053 2009-01-07
- 打赏
- 举报
[Quote=引用 5 楼 caicai_45 的回复:]
呵呵，其实你看怎么看待这个工作量了。
一 面向对象的合理性
一股脑把所有字段都增加到Person里面，这样本来其实就不是合理的做法。
你可以这样来分析， 是不是每个Person都需要一个学号（这个是学生必须要的，但是老师不要），
虽然你不要的地方可以置为null值。
但是就合理性来说，不是我的属性，我干吗要啊？
二 应对变化
当有一天，又增加一个校长这样的继承于Person的对象，你又在Person里面增加一堆校长的特有字段？
将不是校长的这些数据，对应的校长字段，全部置为null？
然后仔细检查下Student和Teacher的实例化的方式，有没有出错的地方。
还是增加一张校长的表，包含Person，对学生和老师没有任何影响来的好？
对扩展开发，对修改封闭。
三 工作量
目前的成熟一点的orm框架，在做持久层的时候，这样的组合关系，基本上可以做到一次性存储。
Student.Save();
如果里面修改了一些Person的属性，可以一并保存到数据库中，不需要你担心过多。
[/Quote]
这样解释，不容易啊
呵呵，其实你看怎么看待这个工作量了。
一 面向对象的合理性
一股脑把所有字段都增加到Person里面，这样本来其实就不是合理的做法。
你可以这样来分析， 是不是每个Person都需要一个学号（这个是学生必须要的，但是老师不要），
虽然你不要的地方可以置为null值。
但是就合理性来说，不是我的属性，我干吗要啊？
二 应对变化
当有一天，又增加一个校长这样的继承于Person的对象，你又在Person里面增加一堆校长的特有字段？
将不是校长的这些数据，对应的校长字段，全部置为null？
然后仔细检查下Student和Teacher的实例化的方式，有没有出错的地方。
还是增加一张校长的表，包含Person，对学生和老师没有任何影响来的好？
对扩展开发，对修改封闭。
三 工作量
目前的成熟一点的orm框架，在做持久层的时候，这样的组合关系，基本上可以做到一次性存储。
Student.Save();
如果里面修改了一些Person的属性，可以一并保存到数据库中，不需要你担心过多。
[/Quote]
这样解释，不容易啊
caicai_45 2009-01-07
- 打赏
- 举报
哎，赚点分真不容易，ORM框架，LZ可以到网上找找，不少好用的
abcyzq 2009-01-07
- 打赏
- 举报
[Quote=引用 7 楼 caicai_45 的回复:]
目前的较为通用的有Nhibernate。vs2008里面的实体框架，目前来看，好像还不是特别成熟（其实是我没怎么用 ^_^）
[/Quote]
与你在5楼第三点提出的有点自相矛盾了哦
目前的较为通用的有Nhibernate。vs2008里面的实体框架，目前来看，好像还不是特别成熟（其实是我没怎么用 ^_^）
[/Quote]
与你在5楼第三点提出的有点自相矛盾了哦
