标签：oop architecture java design-patterns
我继承了一个使用Struts,Spring和Hibernate的大型Java应用程序.我每天处理的类和接口是：Struts动作,Struts ActionForm,值对象,服务接口和实现,DAO接口和实现以及实体.我很清楚其中大多数的方式和原因,但我不确定ActionForm,值对象和实体之间的责任是否正确分离.我还应该提到领域模型(即所有实体)不包含很多(如果有的话)真实的业务逻辑.从本质上讲,这是一个CRUD应用程序,大多数真正的逻辑都在数据库中(糟糕！).无论如何,我想知道几个与Java相关的独特问题：
1)实体和值对象(VO)之间似乎并没有太大的区别,当它们沿任一方向通过服务层时,必须编写很多代码才能相互转换(Struts Action仅处理VO,DAO仅处理实体.因此,VO和实体似乎有些多余.为什么两者都有？
2)VO-Entity转换代码应该放在哪里？服务层,实体,VO？
3)VO直接放置在ActionForms中,并直接绑定到JSP中的标签(例如).这是一个好习惯吗？如果没有,什么是合适的设计？
4)尚不清楚如何正确处理值对象中的外键依赖关系.例如,某些VO具有一个类型字段,以数据库的形式表示一个到类型表中的外键关系.在用户界面中,这会转换为一个下拉字段,供用户选择类型,或者是一个标签,该标签仅显示该类型的文本表示形式(取决于它在哪个屏幕上).现在,VO是否应该具有类型ID的属性,类型的文本表示或同时具有这两者？谁负责两者之间的翻译？何时？
5)VO有一个用于其数据库ID的字段.我以为VO没有身份？这是怎么回事？
我希望这些问题能够引起普遍关注.在这种类型的体系结构中,这似乎一直存在.
另外,我怀疑此架构会严重影响该应用程序,如果您有更好的建议,请继续.但是我主要对上述问题的答案感兴趣,因为不同的体系结构是我现在无法做的长期重构.
解决方法:
1.
考虑DAO-VO转换；这是否有用取决于Hibernate的使用方式.如果整个Web请求处理都在单个Hibernate会话中,则您实际上应该不需要单独的VO.
但是,如果您的DAO层在完成使用DAO之前打开一个会话以检索对象并关闭该会话,则可能在收集和引用其他对象方面遇到麻烦.很有可能它们被延迟加载,这意味着在请求这些属性时仍必须打开会话.
简而言之,在您开始放弃这些VO之前,请仔细,仔细地查看数据库事务和会话边界.
3.
至于以形式使用VO；如果VO很好地映射到JSP,我会说为什么不呢？我或者对数据模型与它所支持的过程紧密匹配感到印象深刻,并且对数据库尚未规范化(这在将来可能会或可能不会造成问题)感到有些怀疑.
回到1.如果您将DAO与延迟加载和收集一起使用,请记住,数据库会话也必须包括JSP阶段,因为在该阶段将读取DAO.
>服务层必须具有一种知道要更改哪些数据库对象的功能,并且id旨在做到这一点.服务层将不得不从数据库中检索DAO并将DAO中的VO写入字段,尽管它显然不需要用VO的ID更新DAO的ID ：)
>您从请求中需要的是外键字段的ID.由于它来自客户端,您可能应该在业务逻辑中检查是否存在具有此类ID的对象.
根据VO是接受异物的ID还是需要异物,您应该：
>设置ID,或者
>使用服务层通过id将异物获取为VO
将其放入您的VO中,并使用服务层进行存储
您的业务层负责翻译,因为服务层仅处理对象检索和存储.文本或id都不是对象,而是对象的标识符.服务层可以
提供搜索功能,但它不需要上下文信息.
如果我没看错您的问题,您的VO就会通过id引用数据库中的其他对象.在这种情况下,请输入ID.如果从客户端获得字符串,则应该在业务层(使用服务层)进行查找,并将找到的对象的ID放入VO.或者,如果未找到ID,则返回正确的错误消息.
作为结束语；除非您知道自己做的很好,否则请勿触摸DAO-VO. Hibernate是功能强大且复杂的工具,看似易于使用.您很容易犯错误,而且很难发现它们.客户和老板都似乎不喜欢在过去可以正常使用的东西中引入错误.
顺便说说;我对DAO-VO的保守态度来自解决由于EJB2到Hibernate过渡中的类似问题而引起的问题.细节在于魔鬼,改变数据层的处理方式是一项重大的重构,即使看起来像是小菜一碟.
标签：oop,architecture,java,design-patterns 来源： https://codeday.me/bug/20191108/2004968.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。