问题描述
在常见的JavaWeb中，一般会有Modal,Controller,View,DAO,Service几个分层，而Modal在其中发挥怎样的贡献呢？莫非两点：1.对对象属性进行增、删、改时，作为新属性的包装，进行整体传递；2.对对象属性进行查询时对查出的数据进行包装以进行传递。然而实践中，我们在删、改、查时，通常只会涉及部分属性，并不经常动用全部属性。那么再用Modal来包装有什么意义呢？如果一个Modal有30个对象，而我通常操作只会涉及一两个字段，那么当我new一个对象时，内存中会分配所有字段的空间，而我只会使用其中一两个，在资源和效率上都产生极大浪费。那么这样面向对象又有什么意义呢？各位看官以为如何？
解决方案
解决方案二：
不要以点盖面，分析肯定是有好有坏的。
解决方案三：
我的看法就是你愚昧无知，没了解深入就在这里发放阙词。
解决方案四：
引用楼主someoneelse888的回复:
在常见的JavaWeb中，一般会有Modal,Controller,View,DAO,Service几个分层，而Modal在其中发挥怎样的贡献呢？莫非两点：1.对对象属性进行增、删、改时，作为新属性的包装，进行整体传递；2.对对象属性进行查询时对查出的数据进行包装以进行传递。然而实践中，我们在删、改、查时，通常只会涉及部分属性，并不经常动用全部属性。那么再用Modal来包装有什么意义呢？如果一个Modal有30个对象，而我通常操作只会涉及一两个字段，那么当我new一个对象时，内存中会分配所有字段的空间，而我只会使用其中一两个，在资源和效率上都产生极大浪费。那么这样面向对象又有什么意义呢？各位看官以为如何？
我认为，你不用怎么知道好不好呢？代码全部写JSP里也很好啊，开发很快啊。
解决方案五：
引用2楼JAVA_LiuTe的回复:
我的看法就是你愚昧无知，没了解深入就在这里发放阙词。
你就是个什么都说不出来的逗逼
解决方案六：
修正下，是“如果一个Modal有30个属性，而我通常操作只会涉及一两个字段”
解决方案七：
有道理哦，比如只想吃鸡头的时候要把整只鸡抓来砍了头才能吃到鸡头。我觉得挺贴切现实的吧，这个整体的思想我觉得比较容易理解和处理吧
解决方案八：
楼主这种情况，考虑加一层DTO，copy需要的属性，其他都是null。建议不要用的太死板了
解决方案九：
1、楼主说的问题其实不是面向对象问题，而是MVC以及分层设计模式问题。即使不是面向对象的语言里，也有分层设计，比如表示层、功能层、数据访问层（DAL，相当于Model的部分功能，看你怎么定义）。2、MVC的设计在软件界非常广泛，各种语言、各种框架、前端的、后端的、中间层的，为什么这么广泛？所以楼主要深入地想想这些问题，然后再回头看看你提到的问题，可能你发现其实小事一桩，可能是局部细节设计不周吧。所以不要把问题扩大化，把整个面向对象都否定了，这就荒谬了。
解决方案十：
引用5楼someoneelse888的回复:
修正下，是“如果一个Modal有30个属性，而我通常操作只会涉及一两个字段”
1.开发中这样的model我没见过，我做金融系统的，最多的一个类也就不到20个字段。2.如果遇到你说的这种情况，确实不建议用对象来传递属性。但用对象传递属性有它的好处:今天你只改俩个字段，明天可能就变成改3、4个了，这时候你基本不用修改接口（甚至实现可能都不用改）。ORM、MVC好处多多，慢慢体会吧
解决方案十一：
引用7楼xiaopeipei2004的回复:
楼主这种情况，考虑加一层DTO，copy需要的属性，其他都是null。建议不要用的太死板了
觉得DTO是个好主意，但是现在很多人的观点是要抛弃DTO，看这里的讨论：
解决方案十二：
引用8楼stonefeng的回复:
1、楼主说的问题其实不是面向对象问题，而是MVC以及分层设计模式问题。即使不是面向对象的语言里，也有分层设计，比如表示层、功能层、数据访问层（DAL，相当于Model的部分功能，看你怎么定义）。2、MVC的设计在软件界非常广泛，各种语言、各种框架、前端的、后端的、中间层的，为什么这么广泛？所以楼主要深入地想想这些问题，然后再回头看看你提到的问题，可能你发现其实小事一桩，可能是局部细节设计不周吧。所以不要把问题扩大化，把整个面向对象都否定了，这就荒谬了。
对，我正好也看到其他人说到过今天改俩字段，后天编程四字段时Modal的优势，但我觉得这样每次对每个属性全部进行alloc是极大的浪费。
解决方案十三：
引用9楼whos2002110的回复:
Quote: 引用5楼someoneelse888的回复:
修正下，是“如果一个Modal有30个属性，而我通常操作只会涉及一两个字段”1.开发中这样的model我没见过，我做金融系统的，最多的一个类也就不到20个字段。2.如果遇到你说的这种情况，确实不建议用对象来传递属性。但用对象传递属性有它的好处:今天你只改俩个字段，明天可能就变成改3、4个了，这时候你基本不用修改接口（甚至实现可能都不用改）。ORM、MVC好处多多，慢慢体会吧
对，我正好也看到其他人说到过今天改俩字段，后天编程四字段时Modal的优势，但我觉得这样每次对每个属性全部进行alloc是极大的浪费。
解决方案十四：
当我new一个对象时，内存中会分配所有字段的空间,你不经常用，给他个null不就可以。
解决方案十五：
引用8楼stonefeng的回复:
1、楼主说的问题其实不是面向对象问题，而是MVC以及分层设计模式问题。即使不是面向对象的语言里，也有分层设计，比如表示层、功能层、数据访问层（DAL，相当于Model的部分功能，看你怎么定义）。2、MVC的设计在软件界非常广泛，各种语言、各种框架、前端的、后端的、中间层的，为什么这么广泛？所以楼主要深入地想想这些问题，然后再回头看看你提到的问题，可能你发现其实小事一桩，可能是局部细节设计不周吧。所以不要把问题扩大化，把整个面向对象都否定了，这就荒谬了。
我可能是用javaweb这个场景来说明面向对象封装导致的内存浪费。在面向对象的各种应用场景中，尤其涉及到数据传递，貌似都会存在这样的弊端。不知道Java有没有LazyAlloc的技术？
解决方案：引用13楼u011461314的回复:
当我new一个对象时，内存中会分配所有字段的空间,你不经常用，给他个null不就可以。
如果我把所有的字段都默认分配成null，会不会导致使用时效率降低，这本质上是在lazyalloc麽？像这样：publicclassPost{privateintid=null;privateStringname=null;privateUserposter=null;privateStringtitle=null;privateList<String>tags=null;privateCategorycategorie=null;privateStringcontent=null;}
解决方案：引用12楼someoneelse888的回复:
Quote: 引用9楼whos2002110的回复:
Quote: 引用5楼someoneelse888的回复:
修正下，是“如果一个Modal有30个属性，而我通常操作只会涉及一两个字段”1.开发中这样的model我没见过，我做金融系统的，最多的一个类也就不到20个字段。2.如果遇到你说的这种情况，确实不建议用对象来传递属性。但用对象传递属性有它的好处:今天你只改俩个字段，明天可能就变成改3、4个了，这时候你基本不用修改接口（甚至实现可能都不用改）。ORM、MVC好处多多，慢慢体会吧
对，我正好也看到其他人说到过今天改俩字段，后天编程四字段时Modal的优势，但我觉得这样每次对每个属性全部进行alloc是极大的浪费。
我就不说你new个对象30个属性都是null到底会浪费多少资源，我没办法量化，但就我理解这对jvm及垃圾收集而言都是小事一桩，不过高并发下肯定是会影响性能。如果你频繁修改接口，哪怕一次，所消耗的开发成本都是很高的，或许你现在感觉不到，代码的高可读性及易扩展是非常重要的，甚至超过你所谓的浪费。这些个框架、规范总是朝着人们更容易理解、接受的方向发展的。扯的有点远...
解决方案：引用7楼xiaopeipei2004的回复:
楼主这种情况，考虑加一层DTO，copy需要的属性，其他都是null。建议不要用的太死板了
真相了，都差点忘记DTO了
解决方案：任何一种技术都是有优点缺点的,我们要做的是找到keyvalue,并解决.
解决方案：我建议楼主看一下关于DDD的书籍，会有答案的。现在大多数项目entity和valueobject根本没有分开
解决方案：支持一下。。。
解决方案：这个不是面向对象的问题，这是你分层的问题，其实对于new一个实体上的浪费不算什么，用了就释放了，倘若不是实体，处理起来就没那么方便了，这是有好也有坏的如果你觉得实在是浪费的话你可以针对每种结构都创建不同的实体，在你的实体提出基类
解决方案：通常会为一个表或者一个功能写一个Modal比如我要增删改查其中的一个字段那你就赋值一个就行了new出来Modal虽然看起来字段多但是set少的话也没什么了而且瞬间执行完内存就释放了不过我们公司已经不用Modal了，封装数据底层都是hashMap实现的，好处就是方便，但是没有get方法看不到里面都有什么属性。
解决方案：引用3楼skgary的回复:
Quote: 引用楼主someoneelse888的回复:
在常见的JavaWeb中，一般会有Modal,Controller,View,DAO,Service几个分层，而Modal在其中发挥怎样的贡献呢？莫非两点：1.对对象属性进行增、删、改时，作为新属性的包装，进行整体传递；2.对对象属性进行查询时对查出的数据进行包装以进行传递。然而实践中，我们在删、改、查时，通常只会涉及部分属性，并不经常动用全部属性。那么再用Modal来包装有什么意义呢？如果一个Modal有30个对象，而我通常操作只会涉及一两个字段，那么当我new一个对象时，内存中会分配所有字段的空间，而我只会使用其中一两个，在资源和效率上都产生极大浪费。那么这样面向对象又有什么意义呢？各位看官以为如何？我认为，你不用怎么知道好不好呢？代码全部写JSP里也很好啊，开发很快啊。
解决方案：引用22楼hjgzj的回复:
通常会为一个表或者一个功能写一个Modal比如我要增删改查其中的一个字段那你就赋值一个就行了new出来Modal虽然看起来字段多但是set少的话也没什么了而且瞬间执行完内存就释放了不过我们公司已经不用Modal了，封装数据底层都是hashMap实现的，好处就是方便，但是没有get方法看不到里面都有什么属性。
哈哈，关键是思路。或者，直接用grails吧，更简洁，更方便。
解决方案：
解决方案：支持一下......
解决方案：引用10楼someoneelse888的回复:
Quote: 引用7楼xiaopeipei2004的回复:
楼主这种情况，考虑加一层DTO，copy需要的属性，其他都是null。建议不要用的太死板了觉得DTO是个好主意，但是现在很多人的观点是要抛弃DTO，看这里的讨论：
没有一种设计适用于全部场景，DTO好不好在于用在哪里.我理解的DTO就是传输过程中的对象而已
其他方案：
可以使用构造方法进行控制码？
解决方案：楼主说的和面向对象无太大关系，世上根本没有完美的代码，完美的设计思想，也许今天的面向对象会被明天另一种更好的取代，但那是需要时间的，一步步发展的。你说的问题我们都有遇到，就语言本身来说也有一定的缺陷
解决方案：楼主说得不错，对象型数据的设计确实存在于这样的问题，在我获取一个对象的时候，但是可能我只要操作极少字段，却把整张表的字段都拿出来了，这对内存的节省以及运行效率是不好的，因此，orm的设计总是比直接数据库操作要慢，不过事物都会有两面性，在于如何取舍。1、orm的设计能更好的建立亲近与业务的模型，而普通数据库设计较为模糊，毕竟它只是品面的保存数据而已。2、orm的设计便于数据的使用和传递，对于开发效率而言比直接用sql提取数据更方便简介，也更贴切于开发语言层面。3、设计问题，就像楼主说的，很多时候一张表N多字段，30个算少了，我碰到过上百字段的，一个对象的提取就要把上百字段全部读取显然是不科学的，但是这不是orm的问题，这是设计的问题，一张表字段过多就需要做分表处理的，然后用一对一关系做链接。4、目前的orm技术已经很完善，基本上都有lazy技术来从一个方面来解决这个问题，无论java内部的机制，还是框架的实现，因此你使用的是框架，而不是自己做的orm，其实也不存在相应问题。5、就目前而言，很多事实证明，一个应用效率和对资源的占用，orm带来的困扰是微乎其微的，更何况现如今硬件环境并不像曾经那么拮据的情况，更多的困扰是一个系统本身的设计问题，例如访问瓶颈，内存泄露，不可理的数据提取方式等等。
解决方案：面向对象是为了解决公用的问题而不是特定问题有时面向对象确实让人不爽但是你真拿它没办法包括设计模式都是把简单的问题复杂化
解决方案：引用28楼u013352832的回复:
我是新手，提个方法：可以使用构造方法进行控制码？
构造方法需要把每个参数都传进去吧
解决方案：引用30楼spiniper的回复:
楼主说得不错，对象型数据的设计确实存在于这样的问题，在我获取一个对象的时候，但是可能我只要操作极少字段，却把整张表的字段都拿出来了，这对内存的节省以及运行效率是不好的，因此，orm的设计总是比直接数据库操作要慢，不过事物都会有两面性，在于如何取舍。
把整张表的字段都拿出来？你确定EF只能这样？
解决方案：
解决方案：这里确实存在一个矛盾，用面向对象的方式操作数据库和面向具体字段的方式操作数据库的是不同的。现在后者运行的更快，但是前者在系统比较复杂的时候更利于提高开发效率。说起来这也算一种有目的的牺牲吧。这种牺牲其实是无处不在的。例如，和计算机打交道，最快的是用机器语言，将各个cpu指令的优化推进到极致，但这带来的巨大的开发难度，因此出现了高级语言。高级语言产生的机器码相当于精心编制的机器码而言，很多都是绕了远路的，但毫无争议的是这种绕远是值得的。
解决方案：引用32楼hjgzj的回复:
Quote: 引用28楼u013352832的回复:
我是新手，提个方法：可以使用构造方法进行控制码？构造方法需要把每个参数都传进去吧
需要几个创建就给几个啊！例如：有20的属性，但是我只需要用3个属性，写一个只有三个构造方法
解决方案：36楼补充下是写一个只带有三个参数的构造方法
解决方案：面向对象只是为了让代码思路更靠近理解思路，方便开发和拓展而已。效率肯定比不上要啥就传啥的。追求效率可以选择C。更快，效率也更高。但是可读性你懂的。
解决方案：引用36楼u013352832的回复:
Quote: 引用32楼hjgzj的回复:
Quote: 引用28楼u013352832的回复:
我是新手，提个方法：可以使用构造方法进行控制码？构造方法需要把每个参数都传进去吧
需要几个创建就给几个啊！例如：有20的属性，但是我只需要用3个属性，写一个只有三个构造方法
假如你一个页面要用到3个属性还有个页面要用到10个属性你咋办再说也没见过模版是用过构造传参的。。