首页新闻找找看学习计划

=========== 面向对象是否真的适合于关系型数据库的应用 =============

0
悬赏园豆:100 [待解决问题]

绝非标题党!!!

让你设计一个类库,让别人调用,其中有一个 User 类,它对应数据库中的 User 表,它有以下字段,这里以 SQL Server举例,
所有字段都是非 NULL,

Id int
UserName nvarchar(256)
ZipCode nchar(6)
PhoneNumber nchar(11)
Comment nvarchar(4000)

假设这个应用是用于银行,Comment 是指用户的信用记录,或是信用报告

假设你的 User 类的属性与上述完全相同

User 类

Id
UserName
ZipCode
PhoneNumber
Comment

假设类需要以下方法
GetAllUsers 获取所有用户
FindUsersByZipCode 查找指定 ZipCode 的所有用户
GetUserById 获取指定的用户

我的问题是,上述三个方法中,你返回的 User 类,是否都包含 User 表中的 Comment 字段的值?

Free.Wong的主页 Free.Wong | 初学一级 | 园豆:20
提问于:2019-05-12 19:50
< >
分享
所有回答(5)
0

你没有将数据传输模型和数据实体分开,请注意适当分层~

yswenli | 园豆:110 (初学一级) | 2019-05-12 20:06

昨天没有理解,今天有其它园友的回复,理解了一些,感谢。。本质上 数据传输模型类,是专用于为 UI 界面设计的没有行为的类。。
其实和自己多建几个POCO类类似

支持(0) 反对(0) Free.Wong | 园豆:20 (初学一级) | 2019-05-13 15:05
0

不必一定返回同一个User类。可以定义多个DTO。我觉得你陷入一个误区,你的设计思路是围绕数据库表来展开的而不是业务逻辑。建议看下DDD相关的书籍

会长 | 园豆:7590 (大侠五级) | 2019-05-13 09:13

感谢回复,有空的话,看看能不能更加仔细的描述下,感谢。。我现在就去了解你上面提到的

支持(0) 反对(0) Free.Wong | 园豆:20 (初学一级) | 2019-05-13 10:34

@heywap:可看看这书:《领域驱动设计》

支持(0) 反对(0) 会长 | 园豆:7590 (大侠五级) | 2019-05-13 13:49

@会长: 好的,感谢你的分享。。。

支持(0) 反对(0) Free.Wong | 园豆:20 (初学一级) | 2019-05-13 15:06
1

不需要都包含,这个comment字段是在特定业务场景才需要使用,你需要根据你的这些类方法来选择性的将这个值塞入

不甘平凡的大公鸡 | 园豆:228 (菜鸟二级) | 2019-05-13 10:03

感谢回复,这个就很奇怪了,你想明明是一个有 Comment 属性 User 类,在有些情况下 Comment 是 null,有些情况是包含表中 Comment 字段的值,是不是很奇怪? 你如何在类的文档中描述 Comment 在什么样的情况下是null,什么样的结果下包含值呢? MembershipUser 类的 Comment 总是包含这个值,如果你真的将 Comment 保存为字符数多达几千的用户信用报告,你的应用性能会非常差。。。。

支持(0) 反对(0) Free.Wong | 园豆:20 (初学一级) | 2019-05-13 10:33

@heywap: 如果在类文档出无法描述null的含义,可针对性的新建一个pojo类,该类即不需要这个字段,user类本身相当于实体类,是要和数据库相关联的。

支持(0) 反对(0) 不甘平凡的大公鸡 | 园豆:228 (菜鸟二级) | 2019-05-13 12:21

@不甘平凡的大公鸡: 感谢你的回复,理解你说的意思,你说的 POJO 是只包含数据不包含行为的 DTO 对象是吧.. 是可以解决问题。。。但缺陷也比较明显,如果你的 User 表,以各种各样的方法来显示数据的话,就存在要写多个不同的 POJO 的问题,而命名真的是个问题。。。 可能有点像这样
UserDTOWithIdUserName
UserDTOWithIdUserNameZipCode

支持(0) 反对(0) Free.Wong | 园豆:20 (初学一级) | 2019-05-13 12:47

@heywap: 首先,按你说的逻辑,一个user类可能会存在很多种业务场景,但你的表中只有一个大字段。而从实际上来看,正常返回实体类数据,我认为只有两种情况,一种是包含大字段,一种是不包含,创建pojo类的目的只是规避一些大字段可能导致的性能问题(最简单的是user类直接塞null),而并非是针对某一个业务就要创建一个。正常情况下,是不可能出现你要什么字段,我就只给你什么字段的情况的,希望可以理解。

支持(0) 反对(0) 不甘平凡的大公鸡 | 园豆:228 (菜鸟二级) | 2019-05-13 16:01

@不甘平凡的大公鸡: 刚刚了解了 DTO ,本质做法就了为了 用户界面 去设计不同的只有数据没有行为的 POCO(POJO) 类。。

支持(0) 反对(0) Free.Wong | 园豆:20 (初学一级) | 2019-05-13 16:34

@heywap: 无论pojo,亦或entity beans,都是为你的业务服务,别想的那么死板,灵活运用

支持(0) 反对(0) 不甘平凡的大公鸡 | 园豆:228 (菜鸟二级) | 2019-05-13 16:36
0

根据具体业务需求返回

~扎克伯格 | 园豆:1837 (小虾三级) | 2019-05-13 10:25
0

移步ef,其他的真不想说什么。其他orm在我眼中不如几十百把行代码。
bean是几乎同样的bean,不同的是计算机中 地址 描述用 引用描述了,而自己控制存储多一个“ID”列 从而进行描述。

结合业务——无非是Filter(Where)、MapReduce(Select)一次(也都是数据权限)。
因此抛开 数据细微的操作:如约束、锁、写入读取性能等,关系数据库 ef+odata or ef + 自行 格式(相当于odata)是快速很爽的选择。

非关系库中linq也是很好的选择,如日志文件,这样在数据权限 动态构建中,可以很灵活的一次性完成比较全能的业务接口,而且也能一次性遍历 构建性能较好的输出运算。

花飘水流兮 | 园豆:10955 (专家六级) | 2019-05-13 23:14
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册