`
zwchen
  • 浏览: 795675 次
  • 性别: Icon_minigender_1
  • 来自: 成都
社区版块
存档分类
最新评论

一种一站式的Java Web框架的设计和实现

阅读更多
这次,我采用对话,FAQ问答方式陈述,因为我觉得它更容易从用户角度去思考问题。
MiniFramework:就是我指的框架,或者说一种思想,Mini的意思是精悍,也就是说开发量小,代码少,开发快。
RoR:Ruby on Rails用Ruby语言写的Web开发框架,非常有潜力,号称比Java开发快10倍。
SSH:Struts(Webwork)+Spring+Hibernate,JavaWeb开发最流行的组合。

MiniFramework和业界已有的框架有什么特别之处吗?

从Java EE(J2EE)分层来划分,有分层和整合框架,譬如表示层的Struts,Webwork,JSF,持久层的Hibernate和 IBatis,JDO。但整合的有Spring和PicoContainer容器。

从开发角度来说,有整合和快速代码生成,前者如AppFuse和SpringSide,后者如JET Emitter。我认为,这两者都没有去解决软件开发的复杂性,更多的只是减少了一点敲代码的时间,而不是减少理解代码的时间,而后者远远大于前者。

MiniFramework综合了上面两者,既是对分层各框架的整合,也是对框架的整合,但是,它会让你的代码量减少到原来的30%左右。更少的代码意味着可以更快开发和变更,更易实现敏捷过程。它是技术和过程的结合。

MiniFramework框架用到了Webwork+Spring+Hibernate,但是,对于开发人员,它们更像是封装好的类库,这意味着你需要了解它们很少,我只用其中我认为最值得的地方。并且是你会发现新的用法,就如同Tapestry框架在html标签中设指令。

MiniFramework是严格遵守MVC职责分离和分层架构的,并且很多都是自动的,譬如透明持久化,页面输入获取。遵循上面的约定,是因为我让它们成为项目开发最佳实践。

你觉得MiniFramework能够真正提高生产率吗?

高质量的软件,有三个因素:Team、Technology、Process:
  • Team:MiniFramework可以让开发人员避开技术引起的复杂性,而专注于业务,并且节省培训成本。
  • Technology:MiniFramework整合了流行框架最有价值部分,譬如Spring的事务处理和IoC,Hibernate的透明持久化,Webwork的control-view关系配置。
  • Process:MiniFramework让J2EE快速开发成为可能,改变了J2EE不适合敏捷过程的论断。敏捷,意味着快速开发,快速变更,快速响应需求。


MiniFramework将会对整个项目开发周期和流程都有很大的改进。

但是,客观的规律,如Brooks 20多年前所说:“没有银弹”。MiniFramework只能解决次要复杂性(Accident),而不能解决软件本质(Essence)复杂性。

原文如下:没有任何技术或管理上的进展,能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
我认为,研究快速开发,必须先了解这个“没有银弹”理论。Brooks先生给我们提供了一些解决方案,很多现在都在用:

技术方面:
  •   Ada和其它高级语言
  •   OOP编程
  •   人工智能和专家系统
  •   “自动”编程
  •   图形化编程和IDE工具

另外还有一些解决方案,我认为现在都在流行
  •   购买构建 vs 自行开发
  •   需求精炼和快速原型
  •   增量开发
  •   优秀的设计人员

但是,大多数企业应用,特别是外包项目,软件的本质复杂性并不大,因为应用软件,特别是商业软件毕竟不同于系统软件,技术往往不是根本的障碍,而是背后的商业需求(怎样才能够最大程度盈利?譬如业务流程再造)。也就是说,我们可以避开“没有银弹”。

关于语言对开发的影响,OO教父Martin Fowler先生的“督导”和“授权”见解,是考虑开发语言选择的重要依据:http://blog.csdn.net/mfowler/archive /2006/07/29/997103.aspx 。

MiniFramework兼顾了这两种。

MiniFramework有哪些核心思想,或是原理?

1、元数据编程
这是MiniFramework中减少代码量和快速开发的一个很重要方面。
MiniFramework中有两类元数据,都非常简单:
  Map和数据库映射 同时我们会避开Hibernate那种复杂的关联映射。而且这种映射可以自动生成。

  JSP页面表单元素类型映射 因为http GET和POST提交数据都是文本key-value键值对,它们和数据库字段类型不匹配,我们必须还原其本来类型,但这个过程是自动化的。我打算开发 eclipse插件,让这个映射代码也自动生成。

  所有容易变更的信息,譬如sql,页面导航,对象实例引用…

2、领域对象的表示:Map和List
MiniFramework里面没有具体的对象,譬如Account,Department,Book,而是以另外一种形式体现:Map,这是它最核心的思想。它可以实现所有具体对象的功能,包括对象图。并且易扩展、灵活。

为什么Map这么关键呢?因为它是领域模型的载体,也是自动持久化的目标对象。了解JSON、YAML和REST对MiniFramework中的map 载体理解很有帮助:

REST:区别于Web Services SOAP协议的另外一种轻量级格式,更是一种Idea。REST和ajax协作开发,简直是绝配。REST是未来Web Services的发展趋势,更倾向于SOA,因为REST是以Resource为导向,而SOAP是以Action为导向,并且简单、易用。

JSON:这是ajax流行起来后,一种轻量集的数据交换格式。参考http://www.json.org/json-zh.html

YAML:在Ruby on Rails和Python这类动态语言最常用的一种文本数据格式,类似于Java最常用的XML,但更适合人读。参考:http://wiki.nirvanastudio.org/wiki/YAML/5%B7%D6%D6%D3%C8%CF%CA%B6YAML

从技术的角度考虑,所有的MIS系统,无非是CRUD增删改查,而CRUD的对象,一种载体形式,就可以是Map和List(Map的复数形式)。

关于数据流的处理,可以参考《面向模式的软件架构:卷一》中的“管道模式”,异曲同工。

当然,复杂的MIS就不只是数据流,更倾向于业务流,譬如ERP中的物料管理,SCM的进销存,OA中的工作流。但它们底层都需要数据流支持。

3、Map和List对象的展现技术:JSTL

当然,我并没有提出什么新东西,我只是提出一种新用法。JSTL是map和list的最好展现方式。如user.department.name,通过具体对象,或是Map对象图,都可以实现。但后者很少人用,因为所有的教程上面都会演示对象模型,用map是忌讳,不OO嘛。 Really?

对象展现技术和对象载体是两个非常关键的部分,关于对象展现的idea,可以参考:

OGNL:这是xwork里面对象属性存取的核心, OGNL也是EL(Expression Language)的一种实现方式。
Associative model of data:不同于关系模型和对象模型的另一种idea。

4、 Map 对象持久化技术:Hibernate
几乎我们所见的大多数Hibernate用法,都是持久化POJO,也就是JavaBean,但是Hibernate也支持另外一种持久化技术:Map持久化(dynamic-map)。

需要特别注意的是:对于Hibernate Map持久化,我只使用它的最基本功能,这意味着开发人员几乎都不需要理解hibernate,我已经将对象的CRUD和基本的List操作都封装起来的,调用工具方法就ok了。

这样,数据的四个最重要的方面中的三个被轻易解决了:对象的载体,对象的呈现,对象的持久化。还有一个,就是对象的复杂查询。

5、对象数据查询技术:Spring JDBC Framework

应该说,这个方面对象的概念是最弱的,因为查询的往往是结果集。Spring的JDBC framework为我们提供了很好的封装的,另外,我在它的基础上再封装一下,开发人员的学习成本就更低了,它返回的也是Map或List。

6、 业务对象BO的CRUD抽象

每个业务对象,譬如UserBO,我们要求它实现其CRUD操作,R(Read or Retrieve)包括Load和ListAll两种。这些方法都是框架自动完成的。

Load:根据ID标识加载对象,以及其相关对象,形成一个Object Graph,但对外是Map(对象标识是OO的基本四特征之一)。
ListAll:List该对象的所有信息,List里面的item是Map。
Insert:可以创建该主对象,如User,但也许需要创建相关对象,如Contact信息。
Update:创建对象。也可以支持不同级别的更新:更新用户信息,更新密码,更改用户角色等不同操作。像审批流程的通过和驳回,都是update操作。当然,从性能角度考虑,可以分解。
Delete:删除指定对象,以及相关对象,如删除User,其Contact也必然要删除。

任何业务对象都可以这么抽象划分并且实现,但是,复杂查询就需要单独的sql,利用MiniFramework提供的查询helper类处理,返回Map 或List。

7、 敏捷开发过程

更少的代码,意味着更快的开发速度,这和敏捷过程是呼应的。现在流行的Ruby on Rails,既是一种快速开发框架,更是实践了敏捷开发的idea。MiniFramework做快速原型非常方便,而且这种原型可以直接用做后续开发。快速原型是理解需求的一大利器!

而且,我们严格要求测试驱动,分层架构为容器外测试提高了保证。

Note:个人也觉得,Rails框架比较适合于互联网开发,Java更适合企业开发。因为企业开发很重视事务处理、团队协作、可维护性、语言的简单性,某些方面是Rails所欠缺的。我现在用Rails和MiniFramework开发同一个demo,我觉得它们的开发效率相差不大。

关于语言的设计和比较,请参考书籍《Concepts of Programming Language》

你在MiniFramework中选择框架的依据是什么?

需要特别说明的是,MiniFramework并不依赖于具体的框架,那些框架只是这种思想的一种实现罢了,可以在.net下实现,也可以自行开发一套,都不难。

而且,我认为没有开发轮子的必要。

我并没有提到Webwork,因为它可以轻易被替换掉,而且我用自己前段时间开发的一个web框架,也完全够用,用Webwork主要为了应对不可预期的复杂性和健壮性,另外,Webwork的易用性,比起Struts,Tapestry,JSF等要简单得多。

用Spring,应该说差不多是个必须,因为它提供的声明式事务处理,为开发节省了大量代码,让代码更清晰。结合JOTM,可以实现分布式事务。另外,项目中业务对象引用复杂时,Spring的IoC容器还是很管用。Spring的AOP,为MiniFramework的扩展,提供了便利。

用Hibernate,是因为它把我想做的工作都做好了,它让我放弃了自己开发一个持久化Map框架,另外,Spring整合了Hibernate事务。而且,Hibernate支持数据库移植,这是一个特别关键的特性。

对于技术人员,知道一种框架什么时候用与不用,比学会用一种框架更重要。

MiniFramework的架构,你能够大致描述一下吗?

为了保证开发的简单、灵活性,MiniFramework在架构上做了极大的简化,方便、实用、快速是它的原则,在MiniFramework架构考虑中,我们会在常用的J2EE架构上做减法,而不是做加法。但我们会恪守几个设计的基本原则:松耦合、高内聚、职责分离。

在参考常用的架构模式和设计模式过程中,我一直在思考这个问题:为什么我需要XX模式,我可不可以不要XX模式?

下面是我认为在MiniFramework设计过程中几个核心概念:

MVC(Model 2):为什么我需要MVC?因为MiniFramework是定位在交互式的GUI应用上。经验和理论告诉我,MVC是GUI应用设计的基本原则,它保证了清晰职责分离,方便开发、测试和维护。在MVC架构模式理论中,一般遵循Change->Publish,也就是Observer模式,类似于 message系统,但Web应用的本质(HTTP无状态协议,它怎么可能知道客户端的你?),可以用Request->Push(推模式),区别于Pull(拉模式)。我更倾向将MVC说成Model 2,区别于Model 1,也不同于MVC。在实际开发中,JSP是作为html模板,只被动接收Request中push过来的对象,决不主动去pull。

Note:Push和Pull,同步和异步,对软件设计很多时候有决定性的影响。

分层架构:分层架构有助于将大系统分解成子任务,每个子任务限制在一个特定的层次上,层间从上到下依赖,从下到上是松耦合。TCP/IP分层模型是它的最好证明。正如OSI 7层模型的实用模型是TCP/IP 4层模型。MiniFramework中,用户接触到的是两层:表示层和业务层,是J2EE和.NET架构的一种折中。在用MiniFramework开发时,持久层被封装起来,成为一些简单的Helper类,不是独立的一层。

严格的分层,可以让表示层的UI用Dreamweaver开发,业务层容器外测试,实现敏捷开发。

接口:在分层模型中,一般都非常强调接口,因为可以让上层只依赖于下层的接口,而不是实现,这样实现可以任意替换和变更,在网络开发,特别是和协议打交道的时候,我们会体会到这种设计的优雅。另外,在组件式开发中,我们也倾向于提供接口。

但是,应用MiniFramework,我们倾向于纵向开发,也就是说,某个模块从表示层到持久层都是一人开发,而不是横向:表示层的去调用业务层开发人员的业务层。这时候,纵向开发就不太适合用接口了,因为接口规范完全由本人把握。这时接口很可能只会带来臃肿,和难维护,一点改动往往牵一动百。当然,在某些情况,如开发Mock测试,Web Services,接口还是很有必要。另外,有人说,我用接口可以实现任意层替换啊?譬如我现在用Hibernate,以后换成IBatis。这完全是一个谎言,至少我看到的大多数应用,将Hibernate换成IBatis的成本绝不亚于重新开发,因为耦合太大。另外,我有个疑问:需要更换的可能性有 1%吗?

个人觉得,接口比较适合于系统软件开发,而不是商业软件开发;而抽象类的继承机制比较适合商业软件开发,而不是系统软件开发。为了复用,系统软件开发倾向于组合,而不是继承。

Business Object、ActiveRecord和ORM:不同于常用J2EE开发的ORM,也不同于RoR的ActiveRecord, MiniFramework用Business Object来调用持久化的Helper类,而且它是stateless的。没有ActiveRecord的高耦合,也没有ORM的复杂性。

主要参考文献:
《Pattern-Oriented Software Architecture: Volume 1》
Model 2:http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html
《Patterns of Enterprise Application Architecture》
《Core J2EE patterns》


用MiniFramework开发,它的驱动模式是什么?


现在做项目,一般有三种开发模式:
  •   数据驱动:倾向于从E-R图来设计系统,早期的两层架构,如VB、PB。现在的Web开发也很多选择这种。因为数据才是企业的核心。数据驱动往往为性能考虑很周到。
  •   领域驱动:在复杂的业务系统,譬如物流、金融领域,都有自己的领域模型,分析这些业务本质的抽象,是进行大规模开发和后期维护的保证。
  •   页面驱动:倾向于交互式系统(不同于电信那种以业务为核心的系统),GUI往往就是需求本身。而且,先做出页面原型,和客户交流,对于理解需求非常关键。另外,一般的MIS系统,页面驱动很容易理解,譬如电子政务。


MiniFramework更倾向于页面驱动和数据驱动,而且MiniFramework很容易将Model Driven Design转化为实际可运行代码。象银行系统,底层多是C写的,并没有对象的概念,但并不是说没有领域模型。

MiniFramework现在很完善了吗?

还是beta阶段,但是我认为对一般的项目应该够用,我已经做了完整的CRUD例子,其中有三表关联,还是有一定复杂性和代表性。

但是,我现在也在思考一个真正的企业级框架,如果说它是1.0版本的话,MiniFramework就是0.1版了,距离还很远。但我大致上思路很明确,除了以上的idea外,我还会加入以下idea和功能:
  •   Event Driven:提高系统的可扩展性和灵活性,将Map数据作为Event的一个部分,而不是现在的全部。
  •   Business Controller(Interceptor):相同职责统一控制,譬如权限;所有关键数据的 createdTime,createdBy,updatedTime,updatedBy统一处理;Audit等。
  •   Micro Kernel:为应用开发提供良好的适应性和扩展性,适应需求,譬如Message-based。
  •   Service Engine:为一些常用的服务提供统一的调用方式,譬如报表系统特别强调的订单号相关服务,如作业调度,消息系统
  •   支持分布式协议:SOAP,REST,RMI,
  •   支持多种客户端:WAP,Browser,Client,PDA
  •   对集群、安全的灵活支持

上面的很多概念并不是来源于MIS系统,但是我想将其思想引入到MiniFramework中,但还要保证MiniFramework的简单、易用。

你也知道,公司都是利润驱动的,MiniFramework对公司提高利润有那些帮助呢?

从上面的“生产率”FAQ我已经解答了部分,现在我要从整个软件生命周期的角度考虑:

  •   需求调研和需求分析阶段 MiniFramework可以帮助快速开发原型,和用户确认,了解客户真实的需求。
  •   架构和设计阶段 MiniFramework可以简化架构,因为MiniFramework里面蕴含了一种架构思想。
  •   编码和测试阶段(开发阶段) 这是MiniFramework最强劲的地方,下面会代码演示。
  •   集成和交付 前期工作都做好了,这个会难吗?
  •   维护阶段 这可能是项目周期中耗时最多的部分,用MiniFramework写出的代码简洁,灵活,应该不会让维护的代价呈几何级数增加。

但是,在项目开发过程中,一般不建议瀑布模型,因为那样风险太大。MiniFramework倾向于敏捷UP,这是由MiniFramework设计决定的,也就是增量迭代、测试驱动、快速开发,及时反馈。

再说利润的问题吧。
如果从公司盈利点出发,我们可以抛开维护这个漫长的过程(绝不是逃避),因为它往往在合同之外。

因为开发可能只是占项目整个周期中的50%左右,而且在开发过程中,梳理业务和团队沟通可能占去开发的30%,那么另外的70%,也就是 MiniFramework和其它流行组合,如SSH的可比较之处。

虽然我认为代码量可以减到原来的30%,但并不意味着开发速度可以提高70%。如果和SSH传统的使用的方式带来的复杂性比较,MiniFramework可以将开发效率提高50%。

计算一下,就是1 * 50% * 70% * 50% = 17.5%, 也就是说可以提高17.5%, 不敢象RoR宣称10倍的提高,那可是1000%啊!而且,在demo讲解的时候,我会把开发实现方式,和RoR、SSH一一比较。

但是,我已经多次强调,MiniFramework不只是对开发产生影响,还有伴随它的敏捷流程,它让这种流程的实现成为可能,这也是节省成本的方式。

我认为,RoR对开发效率的提高,更倾向于个人,而不是团队,个人开发极大的减少了沟通成本。RoR是框架和过程完美结合的典范,我认为它对开发效率的级数提高,和它所推荐和采用的敏捷过程联系极为紧密。


开发演示
这部分很长,所以由另外一份文档提供,只有看了代码,才真正领会了MiniFramework的Idea,但看懂所有代码,也许只需要你30分钟时间。
  • sql.rar (1.3 KB)
  • 描述: mysql数据库脚本
  • 下载次数: 967
分享到:
评论
17 楼 zwchen 2007-07-13  
Caixiaopig 写道
最近也在为这个问题感到苦恼~
这也是一个老生常谈的话题
系统的可扩展性和代码的重复性的问题
下了看看楼主是如何解决的,看完了再来讨论。


是什么决定了系统的可维护性和扩展性,也是我现在在思考的问题。

我现在看到两种切实可行的方案:
1、基于Plugin的松耦合架构
主要参考:
Openfire和spark的架构(我的二次开发经历)
OSGi
2、基于事件和消息路由的松耦合架构
主要参考:
http://www.infoq.com/articles/dynamic-routing-using-spring
PageFlow
WorkFlow

另外,我想很多人不赞成我的那个方案,是因为它太不OO了,下面是我思考:

我觉得,现在流行的Webwork+Spring+Hibernate都是偏重分层,Spring里面的业务一般也是Transaction Script方式(《Patterns of Enterprise Application Architecture 》),
而要采用Domain Model,那么会弱化分层(怎么持久化并不关键),我不知道大家怎么去折中这种问题。
不知道大家对《Hibernate in Action》中的Auction例子怎么看法,不过Gavin King没有告诉我们怎么把他的Domain Model和Spring、Webwork优雅的集成。而在without EJB附带的,那个spring-jpetstore例子和Auction是冲突的。

我发现,要是按照领域建模,从需求分析的领域模型,逐渐过渡到设计模型,一次次迭代,两种类图很难match,因为在分析阶段的model里面有方法,在真正实现时,都移到了DAO或Service里面,而DAO和Service是无状态的,Domain其实已经不是Domain,而是Entity。难道领域模型只用来做描述、理解、分析业务?
至少,上面的方式在我经历过的一个大型业务系统是成功的(1200万RMB,50万行Java代码),而且这样做也不影响系统的可维护性。



16 楼 Caixiaopig 2007-07-13  
最近也在为这个问题感到苦恼~
这也是一个老生常谈的话题
系统的可扩展性和代码的重复性的问题
下了看看楼主是如何解决的,看完了再来讨论。
15 楼 basicbest 2007-02-16  
非常好,我也加了你了.
17日10:30-11:30可能有空.
14 楼 LucasLee 2007-02-16  
basicbest 写道
我们的情况类似,大致看了一下其他人的问题,有些在我这里是解决了的。
我们不仅考虑技术,还要综合考虑管理因素,特别是大型项目。
其实国内的软件开发都是做工程的,但是都用做研究的方式来做事情,陷入技术泥潭,却始终只是跟在别人屁股后面“学习”。

你把它叫做framework,我把它叫做platform,
这个platform=framework+supporting tools

这个是经过几个大型项目实践的(功能点在1万左右)

请先看
http://www.iteye.com/topic/51522
40楼
但是那里写的思路不是很清

我的msn:
basicbest@hotmail.com


我很希望听你仔细从头描述一下你的平台。如:平台的动机、目标;利用你的平台如何实现一个基本CRUD功能等。

我也有类似的经验。Msn你何时在线?
13 楼 basicbest 2007-02-15  
我们的情况类似,大致看了一下其他人的问题,有些在我这里是解决了的。
我们不仅考虑技术,还要综合考虑管理因素,特别是大型项目。
其实国内的软件开发都是做工程的,但是都用做研究的方式来做事情,陷入技术泥潭,却始终只是跟在别人屁股后面“学习”。

你把它叫做framework,我把它叫做platform,
这个platform=framework+supporting tools

这个是经过几个大型项目实践的(功能点在1万左右)

请先看
http://www.iteye.com/topic/51522
40楼
但是那里写的思路不是很清

我的msn:
basicbest@hotmail.com
12 楼 dearmite 2007-01-30  
好好的认真的,看了一遍,
学习的地方很多,
但是也有一些不太理解的地方。
想与作者交流一下,OK??
MSN:maguangjinan@yahoo.com.cn
QQ:8195819
11 楼 zwchen 2007-01-18  
想想在这种环境下你会怎么做:你在一家大型IT外包公司,并且你是项目的technical leader,忽然来了一个中型项目,100人月左右,临时调来公司暂时闲着的开发人员,然后期望着这个项目在三个月后上线。

这应该是一个对管理和技术都有挑战性的主题,说说你们的高见吧,先谢谢了!

就说我想到的吧:
1、培训 视成员能力层次,持续的培训,每周三次左右,每次一个半小时;以及对共通出现问题不定时半小时左右讨论和培训
2、做一个简单的集成框架,让人人都容易理解和开发。
3、尽量撇开公司重量级的CMM5,采取一些轻量级的过程管理,如Agile UP
..........

10 楼 zwchen 2007-01-17  
引用
但感觉这种Map+hbm.xml的方式并不比POJO+annotation的方式快,而且维护成本更大。写个POJO,用IDE生成get,set方法很快就搞定了。以前也试过写个程序用map来描述数据,过了几个月后再去改这个程序时,还要回头查某个 map里面到底有些什么key,如果是pojo,一目了然。
个人觉得手动维护hbm.xml文件简直就不是一般的麻烦,现在一般都是用annotation或用xodclet生成

可能是我们的开发环境限制,因为我们这边中大型项目较多,100-400人月(大项目分成中小项目),一般限制在jdk1.42,因为应用服务器对jdk版本支持不够,如Websphere6.0和Weblogic8.14。另外,项目组成员能力参差不齐,我们希望最大程度节省培训和技术带来的成本,达到开发成本和时间的最优。不过,要是可以用jdk1.5,譬如jboss4.0就对它支持很好,这样用annotation和xdoclet也确实很不错,但是,由于我的对象是map弱类型的,这两项技术可能都用不着。
在维护map结构时,我们的建议是,对照jsp页面和hbm.xml文件,因为BO里面的数据直接来源于jsp页面的表单(以及get请求)。
而且,在RoR里,大概也没有你说的一目了然吧,我觉得这种POJO只是大多数人用Java做Web开发形成的习惯罢了,未必在所有情况下都是最好的选择。
引用
手动维护hbm.xml文件简直就不是一般的麻烦

注意,我这儿的hbm.xml文件里面都是plain结构,删掉了所有关联,一个中大型项目所有的hbm.xml完全由一个人维护一点也不难。
9 楼 蓝色之心 2007-01-16  
大体看了一下,侧重于技术角度,好象是在SSH的基础上多了一些对Webwork,Hibernate的封装,建议和SSH对比着说一下,更能说明“快速开发”的本意。  
8 楼 Sam1860 2007-01-16  
受教了:)
但感觉这种Map+hbm.xml的方式并不比POJO+annotation的方式快,而且维护成本更大。 写个POJO,用IDE生成get,set方法很快就搞定了。以前也试过写个程序用map来描述数据,过了几个月后再去改这个程序时,还要回头查某个map里面到底有些什么key,如果是pojo,一目了然。
个人觉得手动维护hbm.xml文件简直就不是一般的麻烦,现在一般都是用annotation或用xodclet生成
7 楼 vaja 2007-01-16  
我也有过类似的经历,在刚开始的项目中,Service和DAO两层是分开的,并且DAO层用了接口,结果发现Service几乎全部被架空了。所以后来的项目进行了改进,将Service和DAO两层合并,也不用接口了,因为几乎所有的业务逻辑都是数据库操作,而且数据库变更的可能性极小。
在前端表现层我用的是FreeMarker,比起JSP来开发时效率更快,里面的Macro机制使得很多页面显示逻辑得以封装,整个团队的开发效率可以进一步提升。另外,修改时还没有编译过程,节省时间,报错定位也很准。
这种情况下的开发可能不OO,但在某种程度上可以适合一批项目的开发,团队也容易控制。
6 楼 zwchen 2007-01-16  
以前的项目经历告诉我,实际的软件开发、实际的项目过程,实际的软件架构,特别是在这个占中国软件业非常大比重的外包行业,它们和书本上告诉我们的有很大出入。而且,我们往往忽视了商业项目和产品、系统软件开发的区别。
我还是很认同一些经典书籍的理论,譬如对我影响很大的两本书:
《Applying UML and Patterns》
《Patterns of Enterprise Application Architecture》
但是,如果我们完全照搬,是非常危险的,虽然Martin Fowler先生总是提醒我们要结合实际Context。经常上Javaeye的朋友,一定会发现这样的帖子关注点总是最高的:用Struts+Spring+Hibernate开发时,对PO、dao和service的理解(往往是service太thin了)。就说现在的一个帖子吧:http://www.iteye.com/topic/29867

就像你去人才市场,你觉得企业的宣传广告你很信吗?不过,我们的简历,特别是毕业时候的,又有多少是符合实际的呢?有个60%就很不错了。

Pragmatic 和theoretical,对于我们同等重要。
5 楼 zwchen 2007-01-15  
我忽然感觉遗漏了一个问题,就是代码行数的问题,如果以我demo中的那个例子来看,还不足以说明,因为如果精通Hibernate,像级联保存,级联删除,自动级联更新,这些在Hibernate配置文件里面配好,可能更省代码,而且也会快速开发。
但是,国内真实的项目环境并不是这样,往往精通,或者熟悉Hibernate的都是少数,毕竟中国的软件开发环境大多数是中低端。
另外,我去掉了持久层,只保留的dao helper,是因为,我发现业务比较简单的系统,往往开发人员喜欢在持久层里面写所有的业务,service层只是dao的一个delegate,非常thin。要是这样,我就干脆去掉一层算了,这便是dao helper的由来。
另外,对于一个项目,老板最关心的,不会是技术,而是成本和期限。如果你的团队能力是一个客观水平,除了培训,你怎样设计整合一个框架,让大家都能快速上手,并且减少技术不透明性,减少代码调试时间(Map很容易调试),可能是一个必须面对的客观现实。
我之所以要将Hibernate复杂关联隐射都去掉,而采用手工,主要就是想降低开发难度,把hibernate操作给隐藏起来,毕竟开发是一个团队的事情。我想取得技术和成本的一种平衡。
4 楼 zwchen 2007-01-15  
Lucas Lee 写道
我对你的框架的主要意见在于:你采用代码生成的方式。
  这个方式我认为对于开发速度和可维护性的好处很有限。原因在于,如果你修改了自动生成的代码,那么难以再次使用生成代码同时保持改动不被覆盖。对于代码生成,我认为比较合适的是EJB那样不需要程序员维护的自动生成的代码。

上面这段话我很认同,所以我也没有采用代码自动生成的方式,我采纳你的建议,是以前你回复的这部分:

引用
我的建议还是一样,"元数据"化。
你看你的代码,都已经整理得比较清楚了,我估计你再写几个模块,代码模式、结构基本都一样。(我也经过这么一段时间,开始觉得很规整,有点软件工程的意思,但后来觉得枯燥,总是在重复。)那么究竟哪些地方不同呢?无非就是表名、字段、字段类型等等这些“元数据”是不同的,那么将这些元数据抽取出来,单独定义,那么剩下的不就是完全一样的东西么?那么不就能做成一个统一的唯一的程序么?
就是说,一个支撑、解释程序,加一些元数据,可以构成一套完整的系统。

我这里还没有提及灵活性、扩展性的部分,但至少就简单的数据维护部分,上述思路是适用的。


非常感谢你的关注和耐心!
3 楼 LucasLee 2007-01-15  
我对你的框架的主要意见在于:你采用代码生成的方式。
  这个方式我认为对于开发速度和可维护性的好处很有限。原因在于,如果你修改了自动生成的代码,那么难以再次使用生成代码同时保持改动不被覆盖。对于代码生成,我认为比较合适的是EJB那样不需要程序员维护的自动生成的代码。
  另一个方面,代码生成相对于动态解释而言,主要的优势在于性能比较高。但高了多少?我认为还是比较有限的。无非就是把很多动态的变量,固定在代码里了,比如字段名,动态解释肯定是从配置文件里读到内存里,存在一个变量里,而代码生成就是一个固定的字符串。
  所以从这个角度,你基本上没有采用或者考虑过我的建议。当然这只不过是我的建议而已。

  如果采用动态解释,(即运行时按元数据执行相应的操作,如CRUD),那么hibernate,spring,JSTL等流行的框架和技术很可能无法适用,这也是你难以取舍的地方,一般人都希望将最流行的框架用起来,否则有被主流抛弃之风险,这也是我之前面临的困境,不过我仍然坚持了动态解释的路子。
 
  一个CRUD 1百行代码固然不错,不过就我的元数据编程观点来看,是远远不够的。就基本的、惯用模式的CRUD,我觉得应当只给出表名、字段名、字段对应的组件即可完成。当然,对于更复杂的情形,依然允许通过定制各种属性,接入Java程序来实现。

  给你提一个方向,试想,先抛弃你提到的所有的框架,如果他们给了你困扰的话,不要为了用它而用;然后想想我上面说的目标是否能实现? 我觉得不是那么难的。也欢迎其他人来思考这个问题。
2 楼 vaja 2007-01-15  
直面现实,佩服楼主,研究一下。
1 楼 giscat 2007-01-15  
前阵子看过LZ的文章

与LZ思路类似,也发过相关的文章
http://www.iteye.com/topic/38847
mvc,持久层,连接池,缓存等都是DIY
差不多是一站式的

可分享交流学习下

相关推荐

    java web教程和资料电子书

    Servlet是Java Web开发的基础,它是一种服务器端的Java小程序,可以接收并响应HTTP请求。Servlet通过扩展Java类库中的HttpServlet类来实现,可以处理来自客户端的请求,并向客户端返回响应。学习Servlet,你需要理解...

    DWR js框架 javascript框架 web与java交互 Direct Web Remoting Ajax开源框架

    综上所述,DWR作为一个强大的JavaScript框架,极大地简化了Web开发者在Java和JavaScript之间的交互,提供了一种高效、安全的方法来实现Ajax功能。通过理解并熟练使用DWR,开发者可以构建出更加动态和用户友好的Web...

    Java Web程序设计任务教程

    在Java Web程序设计领域,开发者通常利用一系列技术和框架来构建动态、交互式的Web应用程序。本教程的目的是引导学习者深入理解这些技术,并通过实践提升技能。"Java Web程序设计任务教程"涵盖了从基础到进阶的多个...

    个人博客 java web

    首先,Java Web是一种基于Java技术的Web应用开发框架,它提供了强大的服务器端编程能力,使得开发者能够构建功能丰富的动态网站。Java Web开发通常涉及Servlet、JSP(JavaServer Pages)、JSTL(JavaServer Pages ...

    基于java web的人事管理系统

    8. **IDE(Integrated Development Environment)**:例如Eclipse、IntelliJ IDEA,它们提供了一站式的开发环境,包括代码编辑、调试和部署等功能,便于开发Java Web应用。 在"基于java web的人事管理系统"中,可能...

    Java Web程序设计-1期 《Java Web程序设计》_参考资源_学习参考网站.doc

    Java Web程序设计是开发基于Java技术的Web应用程序的过程,它涉及到使用Servlets、JSP(JavaServer Pages)、JavaBeans、EJB(Enterprise JavaBeans)等技术来构建动态、交互式的Web应用。以下是一些关键知识点,...

    覆盖广的JAVA WEB机试

    Java Web 是一个涵盖广泛的技术领域,它包括了用于构建分布式、动态、交互式的网络应用程序的各种技术和框架。在这个“覆盖广的JAVA WEB机试”中,考生可能会遇到多种关键概念和实践,下面将对这些可能涉及的知识点...

    java web整合开发王者归来1

    Spring MVC是Spring框架的一部分,提供了一种优雅的方式来构建Web应用,而Spring Data则简化了与各种数据存储的交互。此外,可能还涵盖了使用Apache Tomcat或Jetty等应用服务器部署Java Web应用的方法。 再者,现代...

    java web开发用的spring框架

    Spring框架是Java Web开发中的核心框架,它以其依赖注入(Dependency Injection, DI)和面向切面编程(Aspect-Oriented Programming, AOP)的理念,极大地简化了企业级应用的复杂性。Spring框架的设计允许开发者专注...

    Web程序设计18 Web程序设计18 Web程序设计18 Web程序设计18

    Web程序设计是构建和维护基于Web的应用程序的过程,它涵盖了前端和后端开发的各个方面。在Web程序设计中,我们通常关注以下几个核心知识点: 1. **HTML(HyperText Markup Language)**:HTML是构建网页的基本语言...

    Java web 课程设计超市购物系统

    2. **JSP**: JSP是构建动态Web应用的一种技术,它允许在HTML页面中嵌入Java代码,实现了视图和逻辑的分离。在购物系统中,JSP主要负责展示数据,如商品列表、用户信息、订单详情等。JSP标签、脚本元素和EL...

    旅游平台JAVA WEB

    【标题】"旅游平台JAVA WEB"是一个基于JAVA技术构建的在线旅游服务平台,它结合了JAVA WEB、JSP等核心技术,为用户提供了一站式的旅游服务体验。这个平台可能包含了预订机票、酒店、旅游套餐以及景点门票等多种功能...

    java web在线学习

    Struts和Hibernate也是常见的Java Web框架,分别用于控制层和持久层操作。 5. **数据库连接**:Java Web应用通常需要与数据库交互,JDBC(Java Database Connectivity)是Java连接数据库的标准接口,而ORM(Object-...

    Java Web开发详解随书源代码下载

    Java Web开发是构建基于互联网的应用程序的技术,它结合了Java编程语言和Web技术,使得开发者可以创建交互式、动态的网站。"Java Web开发详解随书源代码下载"提供了配合书籍学习的源代码,帮助读者深入理解每个章节...

    Java Web开发教程

    Java Web开发是构建基于互联网应用程序的一种技术,它利用Java语言和相关框架来创建动态、交互式的Web服务。这个教程将涵盖一系列重要的知识点,帮助你深入理解并掌握Java Web开发的核心概念。 1. **Servlet与JSP**...

    Web程序设计13 Web程序设计13 Web程序设计13 Web程序设计13

    Web框架如React、Angular和Vue.js简化了前端开发,它们提供了一种组织代码和构建组件的方式,使得大规模应用的开发更为高效。 此外,安全性是Web程序设计的重要考虑因素。开发者需要了解如何防止SQL注入、跨站脚本...

    Web程序设计19 Web程序设计19 Web程序设计19 Web程序设计19

    3. JavaScript:JavaScript是一种运行在客户端的编程语言,用于实现网页的动态效果和用户交互。理解变量、数据类型、函数、DOM操作等基础知识是必备的。随着ES6(ECMAScript 2015)的发布,JavaScript新增了模板字符...

    java框架各类帮助文档

    本压缩包包含了各类Java框架的帮助文档,旨在为开发者提供一站式解决方案,避免在开发过程中因找不到合适的参考资料而困扰。 1. **Spring框架**:Spring是最流行的Java企业级应用开发框架,其核心特性包括依赖注入...

    技术文档web框架

    Web框架是用于构建Web应用程序的一种软件框架,它提供了一种结构和规范,让开发者能够更高效、更快速地编写Web应用。本技术文档将深入探讨Web框架的核心概念、常用框架及其特性,以及如何利用这些框架来开发高效、可...

    java三大框架

    Web MVC和Spring Web提供了Java Web应用的框架或与其他流行的Web框架进行集成。 就是说可将两者一起使用,达到将两者自身的特点进行互补。 spring 框架介绍 : 它关注的领域是其他许多流行的Framework未曾关注的...

Global site tag (gtag.js) - Google Analytics