|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-04-08
dan 写道 如果沒有DI和IOC設計模式Object就會直接寫在哪裡?(應是類別裡吧!)
類別的成員型態沒有直接寫在類別裡是因DI設計模式 而DI設計模式漸漸演變成IOC模式，類別的成員歸屬 早在塑模時早已決定了，xml與annotation皆是實現設計模式 使用的技術之一，並不是決解專案方向的起點。 建議在使用IOC時依關聯性來做配罝 如果注入的Object是誇域或以其它Objec相關聯以xml 看做uml做配置，無關聯以annotation，所以使用xml 或annotation早在塑模時早已決定，當SD在做IOC時,IOC 的概念性模型在SA時就已成型了，所以使用xml 和annotation依塑模原則來做配置，重點在關聯性 很多人使用xml是因為他們看得關聯性，使用annotation 的人正因為他們看到類別的完整性，確實很多Object成員 本來就屬於此類別正因IOC設計模式才產生xml 和annotation之間的不同調，但是決定一切的還是在 塑模原則上(在塑模可以看到關聯性相依性，及無關聯性模型)。 不得不说这是所有帖子里比较有价值的. |
| 返回顶楼 | |
|
最后更新时间：2008-04-07
ray_linn 写道 dan 写道 如果沒有DI和IOC設計模式Object就會直接寫在哪裡?(應是類別裡吧!)
類別的成員型態沒有直接寫在類別裡是因DI設計模式 而DI設計模式漸漸演變成IOC模式，類別的成員歸屬 早在塑模時早已決定了，xml與annotation皆是實現設計模式 使用的技術之一，並不是決解專案方向的起點。 建議在使用IOC時依關聯性來做配罝 如果注入的Object是誇域或以其它Objec相關聯以xml 看做uml做配置，無關聯以annotation，所以使用xml 或annotation早在塑模時早已決定，當SD在做IOC時,IOC 的概念性模型在SA時就已成型了，所以使用xml 和annotation依塑模原則來做配置，重點在關聯性 很多人使用xml是因為他們看得關聯性，使用annotation 的人正因為他們看到類別的完整性，確實很多Object成員 本來就屬於此類別正因IOC設計模式才產生xml 和annotation之間的不同調，但是決定一切的還是在 塑模原則上(在塑模可以看到關聯性相依性，及無關聯性模型)。 不得不说这是所有帖子里比较有价值的. 謝謝您的認同，因為我打字慢，所以從PG->SD->SA都簡單帶過 沒有詳細的說明，因為從PG->SD->SA的說明要打很多的字， 及要舉例及畫UML圖還要寫出code( xml 和annotation ) 所以才沒加上去。 不過我的想法也許是錯的，如果有不對的地方能不能給點意見。 如果覺的有道理的話看的懂我雜亂的發言，能不能加一些資料上去，因為我文筆不好， 常常讓人看不懂。謝謝! |
| 返回顶楼 | |
|
最后更新时间：2008-09-04
配置的后起之秀，是动态脚本：
Grails用.groovy RoR用ruby 好处是： 1）表达能力强，有好的数据类型支持（如list，map等）； 2）可以用编程所用的语言书写配置文件中的控制逻辑； |
| 返回顶楼 | |
|
最后更新时间：2008-04-07
quaff 写道 还有最烦什么零配置,难道Annotation就不是配置?
不算.annotation算硬编码.不算配置,当然可以叫零配置了. 修改annotation的时候就需要修改.java文件,重新编译为.class文件,这显然是硬编码,怎么说是配置呢? 当然,这里不讨论修改xml是否有意义. |
| 返回顶楼 | |
|
最后更新时间：2008-04-10
看了,没有用过,感觉很疏远!
|
| 返回顶楼 | |
|
最后更新时间：2008-04-18
java越来越复杂
|
| 返回顶楼 | |
|
最后更新时间：2008-04-18
Readonly 写道 零配置不是annotation的功劳，早在struts2还叫webwork2的年代，照样有零配置的方法可以使用。
偶一直认为把annotation当作配置来用是一点好处也没有的，偶在实际项目中见过Model一个field上挂了O/R Mapping, Full Text Index, Validation, Security...整整超过10行的annotation，偶只不过是想看看这个Model有什么field而已，这样把整个一大包乱七八糟的annotation都塞在一个文件里面，不是一个大倒退么？ 确实是这样，这样的文件看上去显得没有主次了。 |
| 返回顶楼 | |
|
最后更新时间：2008-04-20
没有绝对的好与不好啦。
不会经常改变的用annotation，经常会变得用XML。 Hibernate用annotation，因为数据模型不会变来变去，有变化依然可以用xml去覆盖。 Struts和Spring用XML，因为不管是名称匹配还是类型匹配都比较死。 @Trasient这个标签我觉得没有那么“可憎”，在代码中显式的申明某个property是瞬时的是很有意义的。另外JPA/Hibernate中的某些标签其实也是对Java语言的一个补充。在Java（实际上现在几乎所有OO语言都存在这个问题）语言中，对于关联关系的表述不够精确。这方面JPA/Hibernate做得可能还不够，当然这估计也不是它们的初衷。 Hibernate支持JPA的annotation是正确的，我觉得Java发展的一个很大的问题就是各立山头，各自为王。Microsoft不也常常因此被诟病吗？ |
| 返回顶楼 | |
|
最后更新时间：2008-06-09
cats_tiger 写道 XML和annotation确实很难取舍，在我们的项目中Hibnerat Domain用Annotation，习惯之后确实比hbm.xml方便。以前我们是用xdoclet生成hbm的，但是annotation更好用。
Spring目前还没有用annotation，XML集中配置依赖关系很方便，而且Spring的常用配置很简单。 最难搞定的是Struts2了，Result的annotation是不会用的，一来coc风格的配置已经很简单了，二来要我在web.xml加入packages的路径实在不爽。所以只用annotation作验证，但是验证复杂了也很乱：
@Validations(requiredStrings = {
@RequiredStringValidator(fieldName = "model.loginId", message = "登录名是必须的."),
@RequiredStringValidator(fieldName = "model.password", message = "密码是必须的."),
@RequiredStringValidator(fieldName = "model.confirmPwd", message = "请两次输入密码.") }, stringLengthFields = { @StringLengthFieldValidator(fieldName = "password", minLength = "3", maxLength = "32", message = "密码应多于3字符", trim = true) }, emails = { @EmailValidator(fieldName = "model.email", message = "请输入正确的e-Mail.") }, expressions = { @ExpressionValidator(message = "两次输入的密码必须相同.", expression = "model.password==model.confirmPwd") })
这堆代码看着实在恶心，还不如xml呢。遇到这种情况我就让弟兄们随机应变了。 过度滥用和过度设计annotation,会让人哭出声来.正如前面所讨论的,分离关注点. 就这个validations来说,还不是最终设计,因为message要支持国际化,那到时候一样需要各种语言版本的properties文件.我觉得把validations和域对象,尤其是和po混用起来,是污染域对象的行为,相当把校验的逻辑部分包含在model层上,复杂的校验逻辑如何解决?尽管这个域对象能对外声称他是vo,本身po=vo已经能够容忍了,因为他是plain object,我宁可保持po的纯洁,他要解决的问题就是把关系数据库映射到域对象模型上来;假如这个对象仅仅是vo,我可能能够容忍,不过复杂的校验怎么办?分层设计怎么办,我们是不是需要逻辑侵入?总之我们需要一个平衡,如果需要工厂化生产,我们就必须估量这种集合配置带来的问题,从各种方面考量,维护成本,出错概率....,如果只是一个小系统,只是几个类的校验,那就忍忍就算了吧.本来工钱就不够,不是吗? |
| 返回顶楼 | |
|
最后更新时间：2008-06-16
我的意见是这样的：
xml配置文件的目的便是配置，为的是只需修改配置文件就能改动系统的一些逻辑。 annotation本质就是一种代码。 所以不能使用annotation代替xml配置文件，因为这是一种倒退。我们配置的原因是为了修改系统的逻辑无需编译代码。可是annotation是写在代码中的所以必须重新编译代码。 归结起来一句话： 在需要配置的地方使用xml配置文件，那些本身就应该是代码的一部分的应该是annotation。 |
| 返回顶楼 | |
