我总觉得Model实体类的Display属性不科学
Model就Model,非要管显示的活,改个显示名都得重新编译。
谁给我讲下Display的好处。
这个不是Model管显示,而是把VIEW(cshtml)从数据内容中完全解脱出来,使得VIEW只解决版面问题以及数据的组织,而不考虑数据的内容。
这个是MVVM的设计思想。当你要显示一个TextBox的时候,它的标题是什么内容呢?如果在VIEW里编写,就意味着网页设计师要牵涉到内容里面,从团队开发来说是不好的,而有了Display特性后,VIEW只管从Model里获取标题,标题内容是什么就不用关心了。
这个方案还有一个好处:实现多语言的版本。无论你使用什么语言,都是这个VIEW,我们不需要为了实现不同的语言版本而去修改VIEW,只要你提供不同语言版本的数据内容就好了。
Display特性只是一个抛砖引玉的方案,我们可以通过硬编码的方式来编写Model(比如把Model的定义独立到DLL中),不同的语言版本提供一个不同的Model(DLL),是否实现多语言很简单呢?
至于你说的,要修改一个简单的内容,也要重新编译系统,这个确实是一个问题,但是我们可以改变:
1、如前面所说,把Model独立到DLL中,此时,你要编译的只是这个DLL而已
2、自己派生一个Display特性,使得读取Name值的时候可控(比如读取指定的xml、读取数据库等)。这里你可以参考一个开源的网店项目:SmartStore。
表示一直在页面中写Display。适合直接一句代码生成表单。
因为数据的抽象层面不同,所以需要不同的接入口,所以会产生不一样的名称。
比如,在业务逻辑中,12345是一个整数,而在产品层面中,这是一个数值为12345的人民币金额。
而再往下一层,就是数据存储中,不过是一堆1和0的二进制序列。
在不同层次的抽象中,这是相同的对象不同的意义,所以需要不同的接入口。
在硬盘是磁盘位置;在数据库存储层是数据值;在数据库应用层是一个整数;在业务逻辑层是对象的一个属性;在产品就是一个金额。
在不同的抽象层面,就会有不同的名字。
那么Display就是从下层抽象到上层抽象的一个过渡。
至于它用属性的方式写在Model中是否合理这是另一个层面的问题,许多时候我们还是可以用脚本的方式写在外部,避免每次重新编译的,缺点也就是因为定义于对象分开了,有时候比较难知道定义和对象到底放在了哪里。
我觉得是利大于弊,重新编译虽然是个痛,但可以忍。
慢慢习惯吧,所不定用的多了理解也更深刻了。
这种东西又没人强迫你用的,不用也不会死,用了的好处,那个赵本山说过了,
谁用谁知道。