- 浏览: 792967 次
- 性别:
- 来自: 成都
最新评论
-
天塔上的猫:
技术孵化,任重道远啊!不过大哥能力牛逼啊,相信会有实现的一天的 ...
技术孵化的探索之路 -
SIHAIloveYAN:
谢谢分享,刚刚考上研究生,对我有很大的帮助,希望5年后再回到这 ...
我的2015 -
MUMU影子:
...
技术孵化的探索之路 -
tonyyan:
谢谢分享!
Java源码阅读的真实体会 -
cauchenlu:
http://ez.web126.cn/这个不错,完全颠覆目前 ...
一种快速开发的Java Web架构设计和实现(续)
这篇文章写得太粗糙,不想浪费大家时间(原帖删),还是看我后来的改进版吧:
http://www.iteye.com/topic/47085,
虽然它有很大的局限性,但还是值得参考,批判去看它吧。
本文的评论还是值得一读。
为了实现而实现,不好么?为了领域模型而领域模型,好么?
世事无绝对。所谓权衡。
软件的用处是什么?实现业务领域的自动化。领域问题的复杂度是软件必然无法回避的。控制问题可以省略,直接拿UI调用业务代码。DAO可以省略,业务代码可以直接调用JDBC。但是领域问题永远无法省略。
不实现领域模型可能吗?表面上可以,很多软件做出来一个领域概念也没有,一个业务对象也不写,照样运行的很正确。但是业务逻辑已经扩散到UI、控制器、Service、DAO这些东西里面去了,实际的工作一点也没逃掉,该写的业务代码其实一行也没有少写。
不过,这样做项目,感觉只是为了实现而实现,放弃了领域建模那些用Java优势的地方,不过这种优势可能也主要体现在比较复杂的业务系统。譬如用ORM来解决领域模型和E-R模型的不匹配。
为了实现而实现,不好么?为了领域模型而领域模型,好么?
世事无绝对。所谓权衡。
是啊,如果要真的再进一步,就是你说的这个路线了,谢谢你的提醒。
不过,这样做项目,感觉只是为了实现而实现,放弃了领域建模那些用Java优势的地方,不过这种优势可能也主要体现在比较复杂的业务系统。譬如用ORM来解决领域模型和E-R模型的不匹配。
现在倒是想按Lucas Lee 的思路做做看,做做尝试,要是做得比较成功,过段时间就把代码公布出来,再让大家评评。
如果你新加一个简单表,需要的简单流程:
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应用的整个开发,包括基础类,我只花了两天左右的时间。
我的建议还是一样,"元数据"化。
你看你的代码,都已经整理得比较清楚了,我估计你再写几个模块,代码模式、结构基本都一样。(我也经过这么一段时间,开始觉得很规整,有点软件工程的意思,但后来觉得枯燥,总是在重复。)那么究竟哪些地方不同呢?无非就是表名、字段、字段类型等等这些“元数据”是不同的,那么将这些元数据抽取出来,单独定义,那么剩下的不就是完全一样的东西么?那么不就能做成一个统一的唯一的程序么?
就是说,一个支撑、解释程序,加一些元数据,可以构成一套完整的系统。
我这里还没有提及灵活性、扩展性的部分,但至少就简单的数据维护部分,上述思路是适用的。
如果你新加一个简单表,需要的简单流程:
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自然也跟着简化了)
是啊,不过确实应该考虑怎么简化3,不过2我觉得不用砍掉,因为经常遇到客户最后要求将某某字段排序的需求,所以还是在properties文件里面稍微灵活点,而且也方便测试优化sql:直接将sql编辑器里面的代码copy过来修改一下。
5应该没法砍掉吧,不过你的想法很值得我思考。
现在忽然想想,做这样的简单应用也确实没有多大挑战,当初有这种想法,主要是想怎么让项目组的新手可以快速开发,少让他们加点班,因为项目经理只管看到实际效果,其它就什么也不过问了,譬如培训什么的。
做外包,我觉得一般技术含量都偏低,而且做应用软件不像产品,它很多时候并不需要接口,抽象类可能会用些,而在系统软件开发,这是一个必须,所以开发过程中我们会感觉比较别扭,就像论坛有人问有了Service,可不可以不要DAO,其实,这类简单 应用不要也罢。如果我们的项目现在用Hibernate,我们根本不会考虑用iBatis,如果我们花了100W在Oracle上,我们以后根本不太可能考虑用DB2,它和产品开发差距太大了。
不过,做外包,有时还是长见识,譬如我一直在做的一个项目,软件开发费用在1500W,很多子系统。不过某些方面可能不专,因为都是用别人的产品来开发嘛。
如果你新加一个简单表,需要的简单流程:
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自然也跟着简化了)
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,也许和我关系不大。但加班,你得跟着啊。
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直接做很费劲,那这种设计就是通过简化功能来实现开发的快速。
我想现在的结果和你刚开始的想法肯定偏离了方向。我以前的毕业论文和你的这个东西很相似。现在回头看,是别人用了很多时间走出一条路,我也同样花了很多时间重新走出另一条路,最后发现自己走的路和别人走的都到同一点了,但还没有别人的好。(开会了。。最后一句没有说好)
谢谢你的建议。《DDD》这本书我一年前下载过,放在机器里,不过没怎么看,看来我是需要好好读读。不过对现在的MDA自动生成代码,还是保留看法。
去年,我参加过一个物流系统的开发,是一套产品,现在是3.0,700w行代码(一套300W美金),里面有复杂的领域建模,DB表有300多个,那个系统,,有空就研究研究,如果考虑用我这个,肯定死翘翘。
也许是现在做的有些项目,太过简单了吧,谈不上架构,还得多请教请教前辈,所以我这个帖子,也是想得到你们的指点,因为javaeye高手多嘛。
是的,你的观点我很认同。因为我们大半年前做业务分析时用Rose来建模账号+用户+角色+组织结构+权限时,发现必须有领域模型,才易于分析,而且hibernate和领域建模相处很和谐(贫血的model)。
不过,技术这种东西,用一种用多了,你会发现什么你都会想到它怎么解决,但有时候,它可能不是最佳解决方案。我发现,做项目,特别是大项目,做多了,你会发现代码是很小的一块,很多东西是非代码的,而是某个方面的思路:如cluster,权限,事件模型,异步模型,SSO,容器生命周期,这些都是我一年来处理的。
对于你提出的问题,我发表点看法:
1、事务处理:由于我的持久层工具类是基于Spring的,它自动管理数据库连接池,事务可以在Spring配置文件里面declare,这个很简单,不过我的demo代码中并没有配置,以前我处理JTA时候,还用到过JTOM,那个可以嵌入式跑,Spring也提供了简单的集成(JotmFactoryBean),我当时比较典型地应用是在osworkflow集成上。
2、3:这两个看来就没有hibernate灵活了,确实在我这个应用里面处理起来都很机械,不过效率应该更好控制
4、这个可以在Web框架里面解决,这不是我的关注点,而且,我认为基本的Web框架,特别是基于request的,如Struts和webwork,都无法简单解决这个问题,而且解决很复杂,一年前,这个问题我就觉得是web框架的无奈,因为我的action里面这些代码占据了很大一部分。
5、关于VO: 你说的100个字段的table,确实用jdbc直接做很费劲,如果真的有这样的需求,就不用考虑我这个了。不过对于Map这种东西,你看Servlet规范里面的HttpServletRequest,HttpSession,和ServletContext,其实最重要的功能,我认为就是提供了一个Map,特别是HttpSession,简直就是一个Map实例,tomcat的实现中大概确实这样吧,大概是有一个map实例对象处理setAttribute的存值,
我觉得什么应用框架,都有其实用范围,就像很多人看不起EJB,但是,我们仔细看看EJB规范,EJB的目标有三个关键字:分布式、事务、组件模型,这是官方对EJB描述时说的第一句话。而不是JavaBean,OO。当然这些在EJB3.0很有改观。
大家可以把他当作一种解决问题的方式,就行了,特别是一般的非复杂业务系统,中小型应用,譬如电子政务网站。
http://www.iteye.com/topic/47085,
虽然它有很大的局限性,但还是值得参考,批判去看它吧。
本文的评论还是值得一读。
评论
26 楼
mubenchi
2007-02-28
zwchen HISOFT有你这样的高手啊 早知道我不换公司拉,到你手下干活 那学问可是大大的学习!
25 楼
zwchen
2007-02-13
请参考我后续的改进,可以回答
jiming 和蓝色之心 的建议:
[url] http://zwchen.iteye.com/admin/show/47085[/url]
jiming 和蓝色之心 的建议:
[url] http://zwchen.iteye.com/admin/show/47085[/url]
24 楼
蓝色之心
2007-02-06
大体看了一下,框架是在WSH的基础上进行了一些封装,已达到用户更快的使用WSH的效果,
楼主的精神值得肯定,建议楼主能不能写一份文档,用户要做哪些工作,让用户体验你的“快速开发”呢?
楼主的精神值得肯定,建议楼主能不能写一份文档,用户要做哪些工作,让用户体验你的“快速开发”呢?
23 楼
jiming
2007-02-06
为什么不看看 ibatis
22 楼
zwchen
2006-12-16
经过近一周的思考,我发现我所陈述的东西,根本不是什么架构,也不是框架,因为架构和框架的关注点和我陈述的观点关系并不大。也许,只是对某类问题的一种解决方案罢了,或许会比较适合在需求阶段做prototype。希望不要误导大家。
不过,我现在正在考虑怎么去实现一种持久化解决方案,也许不OO,没有ORM(在研究Hibernate实现),但可以比较方便解决某类问题。
下面是我引用RUP文档里面关于architecture的定义和描述,在RUP里面是4+1视图:
Beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives。
在我以前的项目经历来看,架构特别关注以下几点:
可扩展性:譬如eclipse的OSGI,JBoss和weblogic的JMX微内核。
性能:如ebay架构的非cluster,无状态架构,google的服务器集群。
可伸缩性:系统对负载突增的承载能力(负载/响应时间)
安全性
而框架,用google的define:framework 搜索结果:
In software development, a Framework is a defined support structure in which another software project can be organized and developed. Typically, a framework may include support programs, code libraries and a scripting language amongst other software to help develop and glue together the different components of your project.
我觉得,框架特别看重重用、易扩展、灵活。
不过,我现在正在考虑怎么去实现一种持久化解决方案,也许不OO,没有ORM(在研究Hibernate实现),但可以比较方便解决某类问题。
下面是我引用RUP文档里面关于architecture的定义和描述,在RUP里面是4+1视图:
Beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives。
在我以前的项目经历来看,架构特别关注以下几点:
可扩展性:譬如eclipse的OSGI,JBoss和weblogic的JMX微内核。
性能:如ebay架构的非cluster,无状态架构,google的服务器集群。
可伸缩性:系统对负载突增的承载能力(负载/响应时间)
安全性
而框架,用google的define:framework 搜索结果:
In software development, a Framework is a defined support structure in which another software project can be organized and developed. Typically, a framework may include support programs, code libraries and a scripting language amongst other software to help develop and glue together the different components of your project.
我觉得,框架特别看重重用、易扩展、灵活。
21 楼
lane_cn
2006-12-15
Lucas Lee 写道
为了实现而实现,不好么?为了领域模型而领域模型,好么?
世事无绝对。所谓权衡。
软件的用处是什么?实现业务领域的自动化。领域问题的复杂度是软件必然无法回避的。控制问题可以省略,直接拿UI调用业务代码。DAO可以省略,业务代码可以直接调用JDBC。但是领域问题永远无法省略。
不实现领域模型可能吗?表面上可以,很多软件做出来一个领域概念也没有,一个业务对象也不写,照样运行的很正确。但是业务逻辑已经扩散到UI、控制器、Service、DAO这些东西里面去了,实际的工作一点也没逃掉,该写的业务代码其实一行也没有少写。
20 楼
LucasLee
2006-12-14
zwchen 写道
不过,这样做项目,感觉只是为了实现而实现,放弃了领域建模那些用Java优势的地方,不过这种优势可能也主要体现在比较复杂的业务系统。譬如用ORM来解决领域模型和E-R模型的不匹配。
为了实现而实现,不好么?为了领域模型而领域模型,好么?
世事无绝对。所谓权衡。
19 楼
zwchen
2006-12-14
引用
我的建议还是一样,"元数据"化。
你看你的代码,都已经整理得比较清楚了,我估计你再写几个模块,代码模式、结构基本都一样。(我也经过这么一段时间,开始觉得很规整,有点软件工程的意思,但后来觉得枯燥,总是在重复。)那么究竟哪些地方不同呢?无非就是表名、字段、字段类型等等这些“元数据”是不同的,那么将这些元数据抽取出来,单独定义,那么剩下的不就是完全一样的东西么?那么不就能做成一个统一的唯一的程序么?
就是说,一个支撑、解释程序,加一些元数据,可以构成一套完整的系统。
我这里还没有提及灵活性、扩展性的部分,但至少就简单的数据维护部分,上述思路是适用的。
你看你的代码,都已经整理得比较清楚了,我估计你再写几个模块,代码模式、结构基本都一样。(我也经过这么一段时间,开始觉得很规整,有点软件工程的意思,但后来觉得枯燥,总是在重复。)那么究竟哪些地方不同呢?无非就是表名、字段、字段类型等等这些“元数据”是不同的,那么将这些元数据抽取出来,单独定义,那么剩下的不就是完全一样的东西么?那么不就能做成一个统一的唯一的程序么?
就是说,一个支撑、解释程序,加一些元数据,可以构成一套完整的系统。
我这里还没有提及灵活性、扩展性的部分,但至少就简单的数据维护部分,上述思路是适用的。
是啊,如果要真的再进一步,就是你说的这个路线了,谢谢你的提醒。
不过,这样做项目,感觉只是为了实现而实现,放弃了领域建模那些用Java优势的地方,不过这种优势可能也主要体现在比较复杂的业务系统。譬如用ORM来解决领域模型和E-R模型的不匹配。
现在倒是想按Lucas Lee 的思路做做看,做做尝试,要是做得比较成功,过段时间就把代码公布出来,再让大家评评。
18 楼
LucasLee
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应用的整个开发,包括基础类,我只花了两天左右的时间。
我的建议还是一样,"元数据"化。
你看你的代码,都已经整理得比较清楚了,我估计你再写几个模块,代码模式、结构基本都一样。(我也经过这么一段时间,开始觉得很规整,有点软件工程的意思,但后来觉得枯燥,总是在重复。)那么究竟哪些地方不同呢?无非就是表名、字段、字段类型等等这些“元数据”是不同的,那么将这些元数据抽取出来,单独定义,那么剩下的不就是完全一样的东西么?那么不就能做成一个统一的唯一的程序么?
就是说,一个支撑、解释程序,加一些元数据,可以构成一套完整的系统。
我这里还没有提及灵活性、扩展性的部分,但至少就简单的数据维护部分,上述思路是适用的。
17 楼
zwchen
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,很多子系统。不过某些方面可能不专,因为都是用别人的产品来开发嘛。
16 楼
jkit
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自然也跟着简化了)
15 楼
zwchen
2006-12-13
这是我以前写的一篇文章,现在放在Javaeye上,是关于Web开发的总结:http://www.iteye.com/topic/38882,我把它放在了新手区,因为我觉得确实很简单,不知道大家看法如何?
14 楼
zwchen
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,也许和我关系不大。但加班,你得跟着啊。
13 楼
zzname
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直接做很费劲,那这种设计就是通过简化功能来实现开发的快速。
我想现在的结果和你刚开始的想法肯定偏离了方向。我以前的毕业论文和你的这个东西很相似。现在回头看,是别人用了很多时间走出一条路,我也同样花了很多时间重新走出另一条路,最后发现自己走的路和别人走的都到同一点了,但还没有别人的好。(开会了。。最后一句没有说好)
12 楼
zwchen
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不可。但是至少报表本身的展示、传阅、保存、修改,是有一定复杂程度的,即使你的系统中只有一个对象——报表——都是好的,开发和维护过程中,你都可以得到很多方便。
推荐你看一本书:领域驱动设计,蓝色的封面。
但是到了最后,这简单的东西会急剧复杂化,业务代码里面充满了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高手多嘛。
11 楼
zwchen
2006-12-13
together 写道
从数据库开始也不是不可以。但如何把数据库之间的复杂关系完整的映射到系统中去,就是一件很困难的事情了。到时候你的这种方法就不是简单,而是复杂。
所以到最后,你可能会发现,你自己需要写出一个类似hibernate的东西来用的。所以才会出现了hibernate。
从习惯于从数据库开始,到习惯于从java po开始,是非常漫长的一个过程。但这是必须要走的一段路。
所以到最后,你可能会发现,你自己需要写出一个类似hibernate的东西来用的。所以才会出现了hibernate。
从习惯于从数据库开始,到习惯于从java po开始,是非常漫长的一个过程。但这是必须要走的一段路。
是的,你的观点我很认同。因为我们大半年前做业务分析时用Rose来建模账号+用户+角色+组织结构+权限时,发现必须有领域模型,才易于分析,而且hibernate和领域建模相处很和谐(贫血的model)。
不过,技术这种东西,用一种用多了,你会发现什么你都会想到它怎么解决,但有时候,它可能不是最佳解决方案。我发现,做项目,特别是大项目,做多了,你会发现代码是很小的一块,很多东西是非代码的,而是某个方面的思路:如cluster,权限,事件模型,异步模型,SSO,容器生命周期,这些都是我一年来处理的。
10 楼
lane_cn
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不可。但是至少报表本身的展示、传阅、保存、修改,是有一定复杂程度的,即使你的系统中只有一个对象——报表——都是好的,开发和维护过程中,你都可以得到很多方便。
推荐你看一本书:领域驱动设计,蓝色的封面。
但是到了最后,这简单的东西会急剧复杂化,业务代码里面充满了500行的if,十几层的for循环,业务流程都直接挂在数据库上,关联性很复杂。然后就是项目经理不断的强调编程规约,抽出一个个的函数,但是复杂无法得到解决。
现在lz处于这样一个阶段:已经有一定的编程经验,语言方面已经不是问题了。但是对于软件的构架还是有一些糊涂的,搞不清楚层次、对象这些东西究竟是怎样安排的,搞不清楚为什么使用了先进的技术没有使系统变简单,而是变复杂了。于是不相信这些技术,还是相信自己的直觉,靠无微不至的管理措施弥补设计方法的欠缺。
等lz的经验再能丰富一点,就能摆脱现在的状态,不再为了控制器、service、action、dao这些东西伤脑筋,可以把精力更多的放到业务领域上。lz目前的思路还是从技术角度看问题的。比如lz代码中为java程序划分了多个package,这个划分其实是不合理的,完全是从技术的角度划分的,实际上java的package体现的应该是业务领域。
也许你觉得目前接触的项目太简单,不值得使用那么复杂的手段。实际上,你现在干的项目已经有一定的复杂度了。你可以说报表的数据很简单,不值得建立领域模型,直接用sql就可以了,这个我很同意,没有必要任何地方都非oo不可。但是至少报表本身的展示、传阅、保存、修改,是有一定复杂程度的,即使你的系统中只有一个对象——报表——都是好的,开发和维护过程中,你都可以得到很多方便。
推荐你看一本书:领域驱动设计,蓝色的封面。
9 楼
zwchen
2006-12-13
zzname 写道
认真看了一些代码。要实现当前功能代码还是比较干净。但是如果要在这个基础上实现更负责的功能,就不好处理了,或者处理好,但代码结构很别扭。在实际应用中,都会有以下几点功能:
1,事务处理。在对多表操作时中没有看到事务处理的代码。我没有认真看过spring,如果要加上事务,怎么办。
2,条件查询,排序。就是在查询出来的列表中,添加条件查询。按照这种结构思路,如果要增加条件查询,只能有两种选择:
第一,在sql1.properties增加固定条件,在页面获得查询值,把这些查询参数作为参数设置。这种做法只能固定一些字典查询,不能实现动态条件查询。
第二,组织条件sql,比如:where field1=** and field2 = **。编写这个过程的代码是很复杂很费时间的。
3,排序。和第二差不多。
4,页面转跳。这是最麻烦的事情。前面一些问题可以在你代码结构的基础上找技巧可以解决,但这个问题在你代码中没有看到任何解决方案。比如你根据条件(field1=v1 and field2 = v2)获得一个列表,点击其中一个记录的修改按钮,然后在修改页面点击保存按钮,然后回到列表页面,怎样保证那些条件的设置值还保存?在实际系统中,到处是这样的转跳,不复杂,但很麻烦。如果在实现过程中,没有快速开发的解决方案,算不上是快速开发架构。顺便说一下,AJAX的最初出现的原因就是为了解决这种问题。如果不使用AJAX解决,又不解决这个问题,实际是用2年前的思路在开发
另外在代码中,我第一眼发现的是使用Map来代替了VO来保存对象。虽然Map在存取上的时间都达到常量,但总觉得不雅观。即使性能上不考虑,在开发中,获取一个对象的时候,肯定经常要copy字段放入get()中。如果是100多个字段表,开发过程中,其中一个字段对不上,要找出来,够受的。用Map的其它弊端,看看其它人怎么说。
1,事务处理。在对多表操作时中没有看到事务处理的代码。我没有认真看过spring,如果要加上事务,怎么办。
2,条件查询,排序。就是在查询出来的列表中,添加条件查询。按照这种结构思路,如果要增加条件查询,只能有两种选择:
第一,在sql1.properties增加固定条件,在页面获得查询值,把这些查询参数作为参数设置。这种做法只能固定一些字典查询,不能实现动态条件查询。
第二,组织条件sql,比如:where field1=** and field2 = **。编写这个过程的代码是很复杂很费时间的。
3,排序。和第二差不多。
4,页面转跳。这是最麻烦的事情。前面一些问题可以在你代码结构的基础上找技巧可以解决,但这个问题在你代码中没有看到任何解决方案。比如你根据条件(field1=v1 and field2 = v2)获得一个列表,点击其中一个记录的修改按钮,然后在修改页面点击保存按钮,然后回到列表页面,怎样保证那些条件的设置值还保存?在实际系统中,到处是这样的转跳,不复杂,但很麻烦。如果在实现过程中,没有快速开发的解决方案,算不上是快速开发架构。顺便说一下,AJAX的最初出现的原因就是为了解决这种问题。如果不使用AJAX解决,又不解决这个问题,实际是用2年前的思路在开发
另外在代码中,我第一眼发现的是使用Map来代替了VO来保存对象。虽然Map在存取上的时间都达到常量,但总觉得不雅观。即使性能上不考虑,在开发中,获取一个对象的时候,肯定经常要copy字段放入get()中。如果是100多个字段表,开发过程中,其中一个字段对不上,要找出来,够受的。用Map的其它弊端,看看其它人怎么说。
对于你提出的问题,我发表点看法:
1、事务处理:由于我的持久层工具类是基于Spring的,它自动管理数据库连接池,事务可以在Spring配置文件里面declare,这个很简单,不过我的demo代码中并没有配置,以前我处理JTA时候,还用到过JTOM,那个可以嵌入式跑,Spring也提供了简单的集成(JotmFactoryBean),我当时比较典型地应用是在osworkflow集成上。
2、3:这两个看来就没有hibernate灵活了,确实在我这个应用里面处理起来都很机械,不过效率应该更好控制
4、这个可以在Web框架里面解决,这不是我的关注点,而且,我认为基本的Web框架,特别是基于request的,如Struts和webwork,都无法简单解决这个问题,而且解决很复杂,一年前,这个问题我就觉得是web框架的无奈,因为我的action里面这些代码占据了很大一部分。
5、关于VO: 你说的100个字段的table,确实用jdbc直接做很费劲,如果真的有这样的需求,就不用考虑我这个了。不过对于Map这种东西,你看Servlet规范里面的HttpServletRequest,HttpSession,和ServletContext,其实最重要的功能,我认为就是提供了一个Map,特别是HttpSession,简直就是一个Map实例,tomcat的实现中大概确实这样吧,大概是有一个map实例对象处理setAttribute的存值,
我觉得什么应用框架,都有其实用范围,就像很多人看不起EJB,但是,我们仔细看看EJB规范,EJB的目标有三个关键字:分布式、事务、组件模型,这是官方对EJB描述时说的第一句话。而不是JavaBean,OO。当然这些在EJB3.0很有改观。
大家可以把他当作一种解决问题的方式,就行了,特别是一般的非复杂业务系统,中小型应用,譬如电子政务网站。
8 楼
together
2006-12-13
从数据库开始也不是不可以。但如何把数据库之间的复杂关系完整的映射到系统中去,就是一件很困难的事情了。到时候你的这种方法就不是简单,而是复杂。
所以到最后,你可能会发现,你自己需要写出一个类似hibernate的东西来用的。所以才会出现了hibernate。
从习惯于从数据库开始,到习惯于从java po开始,是非常漫长的一个过程。但这是必须要走的一段路。
所以到最后,你可能会发现,你自己需要写出一个类似hibernate的东西来用的。所以才会出现了hibernate。
从习惯于从数据库开始,到习惯于从java po开始,是非常漫长的一个过程。但这是必须要走的一段路。
7 楼
有思想的芦苇
2006-12-13
想知道楼主在那家公司.
发表评论
-
一个优秀的Java企业应用框架的设计和实现
2013-10-25 17:43 52一个优秀的Java企业应用框架的设计和实现: http:/ ... -
一个Java框架引发的思考:语言、框架、范式转换和软件生产力
2011-09-10 13:26 3691前几天,iteye上的pojo同学,发来了他四年前写的一个框架 ... -
电子商务网站,前后台是否该分离?
2011-08-21 12:44 8032做电子商务网站,一般 ... -
Java源码阅读的真实体会
2011-08-20 19:51 25745刚才在论坛不经意间,看到有关源码阅读的帖子。回想自己前几年,阅 ... -
我理解的互联网应用和企业应用开发
2011-07-12 12:01 3164前段时间,我写过一篇该主题的博客,但写完了,我觉得还是没有谈到 ... -
一个在读学生的疑问及我的回复
2011-06-24 11:39 3065我经常收到类似的站内信,然后花上半个来小时回复(我摆文字真的非 ... -
一位技术人员成长历程
2010-05-26 15:52 126044、坚持了第一个月,再坚持半年,以后的学习速度越来越快,你离 ... -
Java虚拟机技术总结(07年写的,原JavaEye精华帖)
2010-04-17 11:15 8348原文:IBM WebSphere Application Se ... -
IBM WebSphere Application Server 诊断和调优(07年写的,原JavaEye精华帖)
2009-12-19 11:07 8244这是上篇文章的续篇, ... -
JBPM源码浅析
2007-09-13 15:04 16429离职啦,工作交接中, ... -
JBPM阶段性工作总结
2007-09-12 15:20 14424快要离职了,工作交接 ... -
AIX学习总结笔记一
2007-07-03 18:07 8480公司项目用到AIX和Websphe ... -
软件开发的一点感想
2007-06-29 10:53 6053这两天,遇到工作中的两个小问题,加深了我以前对软件开发的看法。 ... -
Java线程安全系列(1)--Servlet线程安全
2007-06-16 23:19 13254刚才search的时候,竟然 ... -
从分布式系统的角度看REST
2007-05-28 20:37 3578原帖:http://www.iteye.com/t ... -
也说说项目成败、企业信息化
2007-05-19 15:25 2594这篇文章是我对nbsp同学 ... -
读HSQLDB的源码想到的
2007-05-17 10:36 9229昨天在论坛看到一篇讨 ... -
Web Services开发体会和项目教训
2007-04-21 14:42 52821去年,在一个大型项目( ... -
Seasar Framework介绍(一)
2007-04-21 00:18 10894近段时间,给公司一项 ... -
Struts的html:options 标签内幕
2007-04-20 18:14 7926最近用一个在日本很流 ...
相关推荐
1. **Servlet与JSP**:Java Web开发中的两大基石,Servlet是服务器端的Java应用程序,用于处理HTTP请求,而JSP则是一种动态网页技术,将HTML和Java代码相结合,实现视图层的构建。学习Servlet和JSP的生命周期、请求...
在本资源中,"java web 2.0架构开发与项目实战 源代码01",我们聚焦于Java Web应用程序的开发,特别是在Web 2.0时代的技术和实践。Web 2.0是一个概念,它强调互联网作为交互式平台,用户参与度更高,社交网络和富...
《Java Web开发实践教程——从设计到实现(第2版)》是一本深入浅出的教程,旨在帮助读者掌握Java Web应用的开发技术。源代码是学习编程书籍的重要辅助资源,它提供了书中示例的直观展示,使得理论与实践相结合,...
4. **MVC设计模式**:讲解Model-View-Controller模式在Java Web中的应用,以及如何通过Servlet和JSP实现简单的MVC架构。 5. **JSTL和EL表达式**:介绍JSP标准标签库(JSTL)和表达式语言(EL),如何简化JSP页面的...
《Java Web程序设计任务教程》是一本专注于Java Web开发实践的书籍,由中国工信出版社出版,由传智播客旗下的高端教育品牌“黑马程序员”精心编著。这本书旨在帮助读者掌握Java Web开发的核心技术和实践方法,通过一...
首先,Servlet是Java Web开发的基础,它是一种Java类,用于扩展服务器的功能。Servlet可以处理HTTP请求,生成响应,并与数据库交互。在PPT中,可能会详细介绍Servlet的生命周期、doGet和doPost方法,以及如何通过web...
JSP(Java Server Pages)则是一种视图技术,用于创建动态网页。在这些案例中,你可以看到如何编写Servlet来处理用户请求,以及如何在JSP中嵌入Java代码来展示数据。 2. **MVC框架应用** MVC(Model-View-...
Spring MVC是Java中实现MVC架构的流行框架,它提供了一种组织代码和处理HTTP请求的有效方式。 3. **JDBC与ORM**: JDBC(Java Database Connectivity)是Java中与数据库交互的标准API。ORM(Object-Relational ...
总的来说,这个"java web开发教程全部代码"压缩包是一份全面的教育资源,涵盖了Java Web开发的多个重要方面,包括Servlet、JSP、MVC架构、数据库操作、实时通信以及安全控制。通过深入研究这些代码,开发者不仅能...
在Java Web开发中,Model-View-Controller(MVC)是一种广泛应用的设计模式,它将应用程序分为三个主要组件:模型(Model)、视图(View)和控制器(Controller)。这种分离使得开发更加模块化,有助于提高代码的可...
在Java Web开发中,Model-View-Controller(MVC)设计模式是非常常见的架构。模型负责业务逻辑,视图负责用户界面展示,控制器负责接收请求并调用模型进行处理,最后更新视图。Spring MVC是Java Web中广泛应用的一个...
- Struts2框架技术应用:Struts2是用于简化Java EE Web应用开发的框架,提供了一种模型-视图-控制器(MVC)的架构模式,本书从Struts2的基础概念入手,逐步引导读者了解其高级应用和框架整合。 - Hibernate框架...
1. **Servlet**:Servlet是Java Web开发的基础,它是一种服务器端的Java API,用于生成动态web内容。在轻量级开发中,Servlet可以作为控制器处理HTTP请求,并调用业务逻辑。 2. **JSP(JavaServer Pages)与JSTL...
这是一种常见的Java Web应用架构,它将业务逻辑(Model)、用户界面(View)和控制逻辑(Controller)分离,提高了代码的可维护性和可扩展性。在源代码中,可能会看到Controller类用于处理请求,Model类用于封装数据...
1. MVC(Model-View-Controller):一种将数据模型、用户界面和控制逻辑分离的设计模式,广泛应用于Web开发。 2. 微服务架构:每个服务都是独立的,有自己的数据库,通过API Gateway进行通信,增强了系统的可伸缩性...
JSP则是一种动态网页技术,允许开发者在HTML页面中嵌入Java代码,实现视图与逻辑的分离。 书中可能会深入讲解MVC(Model-View-Controller)设计模式,这是Web应用开发中广泛采用的架构模式。Model代表数据模型,...
在这一章,读者将接触MVC(Model-View-Controller)设计模式,这是Web应用中常用的一种架构模式。MVC帮助开发者分离业务逻辑、视图呈现和用户交互,使得代码更易于维护。可能会讲解如何使用Servlet和JSP实现简单的...
Java Web开发是构建互联网应用程序的一种强大技术,它涵盖了多种技术和工具,使得开发者能够创建功能丰富的、交互式的网页应用。这个“从零开始学JAVA-WEB开发”教程显然是为初学者设计的,旨在帮助他们逐步掌握这门...
RESTful API是一种设计Web服务的风格,强调资源和状态的管理,使用HTTP方法(GET、POST、PUT、DELETE等)来表示操作。在Java Web中,创建RESTful API通常使用Jersey、Spring Boot或Spark等库。这个demo可能展示了...
在Linux环境下进行基于MVC(Model-View-Controller)架构的Java Web开发,是一种常见的实践方式,特别是对于大型、复杂的Web应用程序。MVC模式能够有效地分离业务逻辑、数据处理和用户界面,使得代码更加模块化,...