精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2006-12-13
lz的代码我看了一下,象这样的框架,也许每一个初次搭建项目框架的人都做过一个。我以前也做过这样的东西:前台一个jsp,中间搞一个action,调用一个helper,后面是ado,然后是database。很多人都做过大同小异的东西,好像是该用的东西都用上了,各部分的分工都很明确,然后大家把画面分一分开始干活吧。很简单,很容易就出来看得见的东西,项目经理心里觉得很安全,进度都在控制中。
但是到了最后,这简单的东西会急剧复杂化,业务代码里面充满了500行的if,十几层的for循环,业务流程都直接挂在数据库上,关联性很复杂。然后就是项目经理不断的强调编程规约,抽出一个个的函数,但是复杂无法得到解决。 现在lz处于这样一个阶段:已经有一定的编程经验,语言方面已经不是问题了。但是对于软件的构架还是有一些糊涂的,搞不清楚层次、对象这些东西究竟是怎样安排的,搞不清楚为什么使用了先进的技术没有使系统变简单,而是变复杂了。于是不相信这些技术,还是相信自己的直觉,靠无微不至的管理措施弥补设计方法的欠缺。 等lz的经验再能丰富一点,就能摆脱现在的状态,不再为了控制器、service、action、dao这些东西伤脑筋,可以把精力更多的放到业务领域上。lz目前的思路还是从技术角度看问题的。比如lz代码中为java程序划分了多个package,这个划分其实是不合理的,完全是从技术的角度划分的,实际上java的package体现的应该是业务领域。 也许你觉得目前接触的项目太简单,不值得使用那么复杂的手段。实际上,你现在干的项目已经有一定的复杂度了。你可以说报表的数据很简单,不值得建立领域模型,直接用sql就可以了,这个我很同意,没有必要任何地方都非oo不可。但是至少报表本身的展示、传阅、保存、修改,是有一定复杂程度的,即使你的系统中只有一个对象——报表——都是好的,开发和维护过程中,你都可以得到很多方便。 推荐你看一本书:领域驱动设计,蓝色的封面。 |
|
返回顶楼 | |
发表时间:2006-12-13
together 写道 从数据库开始也不是不可以。但如何把数据库之间的复杂关系完整的映射到系统中去,就是一件很困难的事情了。到时候你的这种方法就不是简单,而是复杂。
所以到最后,你可能会发现,你自己需要写出一个类似hibernate的东西来用的。所以才会出现了hibernate。 从习惯于从数据库开始,到习惯于从java po开始,是非常漫长的一个过程。但这是必须要走的一段路。 是的,你的观点我很认同。因为我们大半年前做业务分析时用Rose来建模账号+用户+角色+组织结构+权限时,发现必须有领域模型,才易于分析,而且hibernate和领域建模相处很和谐(贫血的model)。 不过,技术这种东西,用一种用多了,你会发现什么你都会想到它怎么解决,但有时候,它可能不是最佳解决方案。我发现,做项目,特别是大项目,做多了,你会发现代码是很小的一块,很多东西是非代码的,而是某个方面的思路:如cluster,权限,事件模型,异步模型,SSO,容器生命周期,这些都是我一年来处理的。 |
|
返回顶楼 | |
发表时间:2006-12-13
lane_cn 写道 lz的代码我看了一下,象这样的框架,也许每一个初次搭建项目框架的人都做过一个。我以前也做过这样的东西:前台一个jsp,中间搞一个action,调用一个helper,后面是ado,然后是database。很多人都做过大同小异的东西,好像是该用的东西都用上了,各部分的分工都很明确,然后大家把画面分一分开始干活吧。很简单,很容易就出来看得见的东西,项目经理心里觉得很安全,进度都在控制中。
但是到了最后,这简单的东西会急剧复杂化,业务代码里面充满了500行的if,十几层的for循环,业务流程都直接挂在数据库上,关联性很复杂。然后就是项目经理不断的强调编程规约,抽出一个个的函数,但是复杂无法得到解决。 现在lz处于这样一个阶段:已经有一定的编程经验,语言方面已经不是问题了。但是对于软件的构架还是有一些糊涂的,搞不清楚层次、对象这些东西究竟是怎样安排的,搞不清楚为什么使用了先进的技术没有使系统变简单,而是变复杂了。于是不相信这些技术,还是相信自己的直觉,靠无微不至的管理措施弥补设计方法的欠缺。 等lz的经验再能丰富一点,就能摆脱现在的状态,不再为了控制器、service、action、dao这些东西伤脑筋,可以把精力更多的放到业务领域上。lz目前的思路还是从技术角度看问题的。比如lz代码中为java程序划分了多个package,这个划分其实是不合理的,完全是从技术的角度划分的,实际上java的package体现的应该是业务领域。 也许你觉得目前接触的项目太简单,不值得使用那么复杂的手段。实际上,你现在干的项目已经有一定的复杂度了。你可以说报表的数据很简单,不值得建立领域模型,直接用sql就可以了,这个我很同意,没有必要任何地方都非oo不可。但是至少报表本身的展示、传阅、保存、修改,是有一定复杂程度的,即使你的系统中只有一个对象——报表——都是好的,开发和维护过程中,你都可以得到很多方便。 推荐你看一本书:领域驱动设计,蓝色的封面。 谢谢你的建议。《DDD》这本书我一年前下载过,放在机器里,不过没怎么看,看来我是需要好好读读。不过对现在的MDA自动生成代码,还是保留看法。 去年,我参加过一个物流系统的开发,是一套产品,现在是3.0,700w行代码(一套300W美金),里面有复杂的领域建模,DB表有300多个,那个系统,,有空就研究研究,如果考虑用我这个,肯定死翘翘。 也许是现在做的有些项目,太过简单了吧,谈不上架构,还得多请教请教前辈,所以我这个帖子,也是想得到你们的指点,因为javaeye高手多嘛。 |
|
返回顶楼 | |
发表时间:2006-12-13
zwchen 写道 4、这个可以在Web框架里面解决,这不是我的关注点,而且,我认为基本的Web框架,特别是基于request的,如Struts和webwork,都无法简单解决这个问题,而且解决很复杂,一年前,这个问题我就觉得是web框架的无奈,因为我的action里面这些代码占据了很大一部分。 5、关于VO: 你说的100个字段的table,确实用jdbc直接做很费劲,如果真的有这样的需求,就不用考虑我这个了。不过对于Map这种东西,你看Servlet规范里面的HttpServletRequest,HttpSession,和ServletContext,其实最重要的功能,我认为就是提供了一个Map,特别是HttpSession,简直就是一个Map实例,tomcat的实现中大概确实这样吧,大概是有一个map实例对象处理setAttribute的存值, 如果你认为“这个可以在Web框架里面解决,这不是我的关注点”,那就你的demo代码就只剩下三个特点: 1,抛弃使用VO保存对象,改为使用Map 2,将SQL语句从逻辑代码中分离出来,通过调用资源文件获取 3,调用spring实现操作数据库的基本功能 也就是不包含web层的设计与实现。你的题目:一种快速开发的Java Web架构设计和实现,就应该去掉web架构设计和实现。 如果字段多了,用JDBC直接做很费劲,那这种设计就是通过简化功能来实现开发的快速。 我想现在的结果和你刚开始的想法肯定偏离了方向。我以前的毕业论文和你的这个东西很相似。现在回头看,是别人用了很多时间走出一条路,我也同样花了很多时间重新走出另一条路,最后发现自己走的路和别人走的都到同一点了,但还没有别人的好。(开会了。。最后一句没有说好) |
|
返回顶楼 | |
发表时间:2006-12-13
zzname 写道 zwchen 写道 4、这个可以在Web框架里面解决,这不是我的关注点,而且,我认为基本的Web框架,特别是基于request的,如Struts和webwork,都无法简单解决这个问题,而且解决很复杂,一年前,这个问题我就觉得是web框架的无奈,因为我的action里面这些代码占据了很大一部分。 5、关于VO: 你说的100个字段的table,确实用jdbc直接做很费劲,如果真的有这样的需求,就不用考虑我这个了。不过对于Map这种东西,你看Servlet规范里面的HttpServletRequest,HttpSession,和ServletContext,其实最重要的功能,我认为就是提供了一个Map,特别是HttpSession,简直就是一个Map实例,tomcat的实现中大概确实这样吧,大概是有一个map实例对象处理setAttribute的存值, 如果你认为“这个可以在Web框架里面解决,这不是我的关注点”,那就你的demo代码就只剩下三个特点: 1,抛弃使用VO保存对象,改为使用Map 2,将SQL语句从逻辑代码中分离出来,通过调用资源文件获取 3,调用spring实现操作数据库的基本功能 也就是不包含web层的设计与实现。你的题目:一种快速开发的Java Web架构设计和实现,就应该去掉web架构设计和实现。 如果字段多了,用JDBC直接做很费劲,那这种设计就是通过简化功能来实现开发的快速。 我想现在的结果和你刚开始的想法肯定偏离了方向。我以前的毕业论文和你的这个东西很相似。现在回头看,是别人用了很多时间走出一条路,我也同样花了很多时间重新走出另一条路,最后发现自己走的路和别人走的都到同一点了,但还没有别人的好。(开会了。。最后一句没有说好) 是你说的这么回事,web层的东西我是通过webwork去做的,不过不要model,也许是对JavaBean有些烦了吧(只有get set方法那个)。另外,最主要的就是项目团队的问题,大多数人不会web开发,真不知道怎么让别人快速上手,其实webwork,Spring,Hiberante这些东西挺简单的,至少很多核心源码我都读过。但别人不会用,随便用,最后搞乱套了,烦啊,不过我不是leader,也许和我关系不大。但加班,你得跟着啊。 |
|
返回顶楼 | |
发表时间:2006-12-13
这是我以前写的一篇文章,现在放在Javaeye上,是关于Web开发的总结:http://www.iteye.com/topic/38882,我把它放在了新手区,因为我觉得确实很简单,不知道大家看法如何?
|
|
返回顶楼 | |
发表时间:2006-12-13
zwchen 写道 Lucas Lee 写道 我看了超过5分钟,没看出来是什么逻辑。
解释一下,比如新加入一个简单的表,如客户类型,只有两三个字段的,需要配置哪些东西,写那些代码? 如果你新加一个简单表,需要的简单流程: 1、在db里面创建该表 2、在sql1.properties里面定义一条sql语句,如client_type_insert=insert into.....,并且在db的sql编辑器下测试通过 3、写ClientTypeService类的CRUD操作,继承于BaseService,请对照UserService。对于一般的操作调用,之用调用pm(PersistenceManager)和qm(QueryManager)进行操作就ok了,不过其它的,如存储过程,需要扩充那两个类,因为现在它们还不完整。 4、写ClientTypeService的单元测试代码,如ClientTypeServiceTypeTest。 5、写ClientTypeAction类,继承于BaseAction,参考UserAction 6、用dreamweaver写jsp页面,不过建议,95%的情况只需要将jsp当作模块语言,如freemaker。 你接下来应该考虑怎么实现下面的东西,否则不能算快速开发。 引用 砍掉2,5 简化3, (4自然也跟着简化了) |
|
返回顶楼 | |
发表时间:2006-12-13
jkit 写道 zwchen 写道 Lucas Lee 写道 我看了超过5分钟,没看出来是什么逻辑。
解释一下,比如新加入一个简单的表,如客户类型,只有两三个字段的,需要配置哪些东西,写那些代码? 如果你新加一个简单表,需要的简单流程: 1、在db里面创建该表 2、在sql1.properties里面定义一条sql语句,如client_type_insert=insert into.....,并且在db的sql编辑器下测试通过 3、写ClientTypeService类的CRUD操作,继承于BaseService,请对照UserService。对于一般的操作调用,之用调用pm(PersistenceManager)和qm(QueryManager)进行操作就ok了,不过其它的,如存储过程,需要扩充那两个类,因为现在它们还不完整。 4、写ClientTypeService的单元测试代码,如ClientTypeServiceTypeTest。 5、写ClientTypeAction类,继承于BaseAction,参考UserAction 6、用dreamweaver写jsp页面,不过建议,95%的情况只需要将jsp当作模块语言,如freemaker。 你接下来应该考虑怎么实现下面的东西,否则不能算快速开发。 引用 砍掉2,5 简化3, (4自然也跟着简化了) 5应该没法砍掉吧,不过你的想法很值得我思考。 现在忽然想想,做这样的简单应用也确实没有多大挑战,当初有这种想法,主要是想怎么让项目组的新手可以快速开发,少让他们加点班,因为项目经理只管看到实际效果,其它就什么也不过问了,譬如培训什么的。 做外包,我觉得一般技术含量都偏低,而且做应用软件不像产品,它很多时候并不需要接口,抽象类可能会用些,而在系统软件开发,这是一个必须,所以开发过程中我们会感觉比较别扭,就像论坛有人问有了Service,可不可以不要DAO,其实,这类简单 应用不要也罢。如果我们的项目现在用Hibernate,我们根本不会考虑用iBatis,如果我们花了100W在Oracle上,我们以后根本不太可能考虑用DB2,它和产品开发差距太大了。 不过,做外包,有时还是长见识,譬如我一直在做的一个项目,软件开发费用在1500W,很多子系统。不过某些方面可能不专,因为都是用别人的产品来开发嘛。 |
|
返回顶楼 | |
发表时间:2006-12-14
zwchen 写道 Lucas Lee 写道 我看了超过5分钟,没看出来是什么逻辑。
解释一下,比如新加入一个简单的表,如客户类型,只有两三个字段的,需要配置哪些东西,写那些代码? 如果你新加一个简单表,需要的简单流程: 1、在db里面创建该表 2、在sql1.properties里面定义一条sql语句,如client_type_insert=insert into.....,并且在db的sql编辑器下测试通过 3、写ClientTypeService类的CRUD操作,继承于BaseService,请对照UserService。对于一般的操作调用,之用调用pm(PersistenceManager)和qm(QueryManager)进行操作就ok了,不过其它的,如存储过程,需要扩充那两个类,因为现在它们还不完整。 4、写ClientTypeService的单元测试代码,如ClientTypeServiceTypeTest。 5、写ClientTypeAction类,继承于BaseAction,参考UserAction 6、用dreamweaver写jsp页面,不过建议,95%的情况只需要将jsp当作模块语言,如freemaker。 整个过程熟练后,写代码很快,不知道大家是否以前有asp和php的开发经历?有就更好了。因为只有对比才理解深刻。 本应用的缺点: 1、当操作的table字段太多时候,在service层里给参数赋值确实有些烦琐,虽然很简单,hibernate为我们自动做了,但对于新手,配置那些1:1,n:1,n:n的关联,lazy loading,以及cascade和inverse很花时间,当然高手就另当别论了。 2、从jsp页面字段、到db操作字段的对照关系,这些都必须清楚,也就是说数据的key是层间约束的。其实用asp和php时这些都是默认规则。 另外,系统肯定有一些不完善的地方,因为那个demo应用的整个开发,包括基础类,我只花了两天左右的时间。 我的建议还是一样,"元数据"化。 你看你的代码,都已经整理得比较清楚了,我估计你再写几个模块,代码模式、结构基本都一样。(我也经过这么一段时间,开始觉得很规整,有点软件工程的意思,但后来觉得枯燥,总是在重复。)那么究竟哪些地方不同呢?无非就是表名、字段、字段类型等等这些“元数据”是不同的,那么将这些元数据抽取出来,单独定义,那么剩下的不就是完全一样的东西么?那么不就能做成一个统一的唯一的程序么? 就是说,一个支撑、解释程序,加一些元数据,可以构成一套完整的系统。 我这里还没有提及灵活性、扩展性的部分,但至少就简单的数据维护部分,上述思路是适用的。 |
|
返回顶楼 | |
发表时间:2006-12-14
引用 我的建议还是一样,"元数据"化。 你看你的代码,都已经整理得比较清楚了,我估计你再写几个模块,代码模式、结构基本都一样。(我也经过这么一段时间,开始觉得很规整,有点软件工程的意思,但后来觉得枯燥,总是在重复。)那么究竟哪些地方不同呢?无非就是表名、字段、字段类型等等这些“元数据”是不同的,那么将这些元数据抽取出来,单独定义,那么剩下的不就是完全一样的东西么?那么不就能做成一个统一的唯一的程序么? 就是说,一个支撑、解释程序,加一些元数据,可以构成一套完整的系统。 我这里还没有提及灵活性、扩展性的部分,但至少就简单的数据维护部分,上述思路是适用的。 是啊,如果要真的再进一步,就是你说的这个路线了,谢谢你的提醒。 不过,这样做项目,感觉只是为了实现而实现,放弃了领域建模那些用Java优势的地方,不过这种优势可能也主要体现在比较复杂的业务系统。譬如用ORM来解决领域模型和E-R模型的不匹配。 现在倒是想按Lucas Lee 的思路做做看,做做尝试,要是做得比较成功,过段时间就把代码公布出来,再让大家评评。 |
|
返回顶楼 | |