=========== 面向对象是否真的适合于关系型数据库的应用 =============
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 | 初学一级 | 园豆： 20
提问于：2019-05-12 19:50 显示帮助
使用"Ctrl+Enter"可进行快捷提交，评论支持部分 Markdown 语法：[link](http://example.com) _italic_ **bold** `code`。
< > 分享
分享您的问题
所有回答(5) 0 你没有将数据传输模型和数据实体分开，请注意适当分层~ yswenli | 园豆：110 (初学一级) | 2019-05-12 20:06 昨天没有理解，今天有其它园友的回复，理解了一些，感谢。。本质上 数据传输模型类，是专用于为 UI 界面设计的没有行为的类。。
其实和自己多建几个POCO类类似 支持( 0 ) 反对( 0 ) Free.Wong | 园豆：20 (初学一级) | 2019-05-13 15:05 编辑文本 预览 上传图片
Ctrl+Enter键快速提交 0 不必一定返回同一个User类。可以定义多个DTO。我觉得你陷入一个误区，你的设计思路是围绕数据库表来展开的而不是业务逻辑。建议看下DDD相关的书籍 会长 | 园豆：8470 (大侠五级) | 2019-05-13 09:13 感谢回复，有空的话，看看能不能更加仔细的描述下，感谢。。我现在就去了解你上面提到的 支持( 0 ) 反对( 0 ) Free.Wong | 园豆：20 (初学一级) | 2019-05-13 10:34 @heywap:可看看这书：《领域驱动设计》 支持( 0 ) 反对( 0 ) 会长 | 园豆：8470 (大侠五级) | 2019-05-13 13:49 @会长: 好的，感谢你的分享。。。 支持( 0 ) 反对( 0 ) Free.Wong | 园豆：20 (初学一级) | 2019-05-13 15:06 编辑文本 预览 上传图片
Ctrl+Enter键快速提交 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 编辑文本 预览 上传图片
Ctrl+Enter键快速提交 0 根据具体业务需求返回 ~扎克伯格 | 园豆：1837 (小虾三级) | 2019-05-13 10:25 编辑文本 预览 上传图片
Ctrl+Enter键快速提交 0 移步ef，其他的真不想说什么。其他orm在我眼中不如几十百把行代码。
bean是几乎同样的bean，不同的是计算机中 地址 描述用 引用描述了，而自己控制存储多一个“ID”列 从而进行描述。
结合业务——无非是Filter（Where）、MapReduce（Select）一次（也都是数据权限）。
因此抛开 数据细微的操作：如约束、锁、写入读取性能等，关系数据库 ef+odata or ef + 自行 格式（相当于odata）是快速很爽的选择。
非关系库中linq也是很好的选择，如日志文件，这样在数据权限 动态构建中，可以很灵活的一次性完成比较全能的业务接口，而且也能一次性遍历 构建性能较好的输出运算。 花飘水流兮 | 园豆：11209 (专家六级) | 2019-05-13 23:14 编辑文本 预览 上传图片
Ctrl+Enter键快速提交
清除回答草稿
您需要 登录 以后才能回答，未注册用户请先 注册 。