Replies: 5 comments 6 replies
-
|
我简单说几点，可能不一定全面 首先是新版更适合模型分层设计，实体模型是基于Model层设计，可以直接作为logic层或service层使用，而且不需要再传入模型，因为实体模型本身就是数据模型。如果你的项目小，一直都没有分层设计（比如直接在Controller直接调用Model）那么可能对你作用不大。 其次视图模型是新版基于很多使用场景而单独设计的，设计理念就是你说的，我只需要关心我需要的字段，而且最好是方便IDE提示（所以才有显式定义方式），支持映射关联属性，并且最新版本的视图模型也已经可以支持数据写入，所以和实体模型的最大区别其实就是两个：显式定义数据字段和更灵活的字段映射。结合数据库的视图概念也许可以更好理解视图模型，从某种程度上来说，视图模型是把模型及关联模型的特定字段属性封装到一个独立的数据模型中，相比数据库的视图的优势就是可以支持多表写入。 |
Beta Was this translation helpful? Give feedback.
-
|
看了下为了IDE提示，定义了视图模型，那么IDE提示 是否通过给原有实体模型或者模型 定义注解属性来实现呢？ 包括很多facade，IDE 提示也不是很完全。 还有 视图模型可写。我倒是建议 查归查，写归写，可以完全定义一个 静态写入方法，或者和之前验证的场景来 来进行关联数据的写入，所有的数据写入都在原模型或实体模型里产生。togethor 在我看来，只是比原Db::update 多了name 和 id。至于对于数据，不通的场景展示可以定义展示的不同字段。比如后台列表，导出，前台数据 和 前台列表。对不通的人希望看的东西不一样。前台字段越少，性能 越高，后台字段全，后期修改 增加业务方便。定义不通获取器， 然后定义不同的视图模型，达到组合的效果，更加的灵活。包括视图石否也可以做到数据可见范围（动态角色，动态字段，动态条件的查询）。 |
Beta Was this translation helpful? Give feedback.
-
|
包括 有那种不同源数据同步工具，感觉视图模型更可以作为一种 数据对象的转换器的作用来使用，输入a 得到b。最好不带写入的副作用。写入算另外一种修改器了。然后视图模型定义，比如存在 一个主数据表 和 一个或多个附加数据表了。就好像以前看别的人 用模型事件，数据a 在正常 更新后，影响b。 b再定义一些事件后，有可能影响c。 这样追踪一个数据的变化就很麻烦了。所以宁愿简单点，无副作用。所有的写 要么主模型数据，主模型 update， 要么关联数据 用对应类 去更新。后期如果想在对应数据表修改时扩展，加参，加内部逻辑也好。只需在对应方法上CTRL 点击，就能找到所有产生修改的地方。而不是点击一个save 出来一堆模型。 |
Beta Was this translation helpful? Give feedback.
-
|
另外，我曾经优化过 大数据量的导出，用sql函数的case when 来给枚举字段 转语义输出，可比 php拿到数据在获取器来变换性能高多了。也就是说 php的数据对象 查询出来的字段，比你动态对象修改增加、更新属性，内存低，速度快。是不是可以考虑把部分获取器，在定义数据库驱动时，定义如 PDO 新增对特定驱动程序的 SQL 解析器的支持。默认解析器支持： 单引号和双引号文字，使用双引号作为转义机制 这样常量的转换，如开关，xxStatus, 相似业务的订单状态枚举， 是否就无需在各视图或模型内定义多次。我只需在mapping时，用函数转换一次。 |
Beta Was this translation helpful? Give feedback.
-
|
IDE注释只是一方面 模型本身你就可以通过官方ide-helper扩展来支持生成注解， 视图模型的优势就是多模型数据封装和只取需要的数据。读归读，写归写 就完全割裂了对开发体验不好，用户需要学习不同的方法，目前默认就是只能读取，写入是单独控制的，但使用习惯是统一的，你可以根据业务需要自己灵活控制。 |
Beta Was this translation helpful? Give feedback.
-
|
我也觉得视图模型支持写是对的，当时第一反应就是如何实现更新写入。 |
Beta Was this translation helpful? Give feedback.
-
|
一般来说 实体模型和视图模型 不需要同时使用，但Model是必须的 Model之上你用实体模型还是视图模型作为 logic或service层 都可以 多了容易混淆，至于如何选择 我前面也说过区别是什么了 |
Beta Was this translation helpful? Give feedback.
-
|
写入，只针对一对一查询出来的写入才方便把，一对多，你还得加特定条件去更新，或者循环着去更新。 |
Beta Was this translation helpful? Give feedback.
-
你可以去看下 关联更新的相关代码 是支持数据集更新的，当然你也可以单独去更新 保持自己的开发规范即可 |
Beta Was this translation helpful? Give feedback.
-
但大部分情况下 视图模型应该都是一对一关联为主的写入场景 |
Beta Was this translation helpful? Give feedback.
-
|
视图模型有实体模型的所有功能，如果仅仅是需要一个分层那么就用实体模型够用了 如果有数据封装和实体属性定义需求 那么就考虑用视图模型。用视图模型相比实体模型的另外一个优势是 可以基于某个模型配合不同的关联 自由组合出多个视图模型，然后查询的时候无需使用with关联查询会自动查询关联。 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
大佬好，新版很棒，我一直关心新版本。只是有个问题希望大佬能再解答一下。
新版本推出的实体模型和视图模型的用法，包括一些介绍文档、文章，不管是官方文档，qq群里的，我这边都研究过了。具体的用法已经清楚了。
但是我个人还不不理解他们的设计理念，作者能再给介绍一下吗。
我先说下我的理解，如果有不对的请指出。
实体模型，我理解的就是一个带业务字段的service层。大多数mvc的框架都会把逻辑写到model层，过去，model层既要负责字段定义（支持自动），又要定义动态字段（设置器和获取器），还有一大部分人把相关逻辑都写到这里，导致这一层会变得复杂。因此实现了实体模型的设计，model只负责定义字段和动态字段，逻辑写到实体模型。
视图模型和实体模型的背景一样，只不过视图模型只负责输出，并且只输出显示定义的字段。
我的问题是：
除了我刚刚提到的情况，是不是还有其他原因？
什么情况下应该使用新推出的视图模型或实体模型，因为老版模型已经能解决很多问题了？
视图模型是不是可以通过一个方法获取到model，通过model更新一些东西，更新的东西也能自动同步视图模型？
我主要的问题还是第二个，为什么要使用这两个模型，什么情况下应该使用这两种模型，有哪些进步？
Beta Was this translation helpful? Give feedback.
All reactions