zwchen
- 浏览: 799630 次
- 性别:
- 来自: 成都
-
最新评论
-
天塔上的猫：
技术孵化，任重道远啊！不过大哥能力牛逼啊，相信会有实现的一天的 ...
技术孵化的探索之路 -
SIHAIloveYAN：
谢谢分享，刚刚考上研究生，对我有很大的帮助，希望5年后再回到这 ...
我的2015 -
MUMU影子：
...
技术孵化的探索之路 -
tonyyan：
谢谢分享！
Java源码阅读的真实体会 -
cauchenlu：
http://ez.web126.cn/这个不错，完全颠覆目前 ...
一种快速开发的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：
MiniFramework将会对整个项目开发周期和流程都有很大的改进。
但是，客观的规律，如Brooks 20多年前所说：“没有银弹”。MiniFramework只能解决次要复杂性(Accident)，而不能解决软件本质(Essence)复杂性。
原文如下：没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
我认为，研究快速开发，必须先了解这个“没有银弹”理论。Brooks先生给我们提供了一些解决方案，很多现在都在用：
技术方面：
另外还有一些解决方案，我认为现在都在流行
但是，大多数企业应用，特别是外包项目，软件的本质复杂性并不大，因为应用软件，特别是商业软件毕竟不同于系统软件，技术往往不是根本的障碍，而是背后的商业需求（怎样才能够最大程度盈利？譬如业务流程再造）。也就是说，我们可以避开“没有银弹”。
关于语言对开发的影响，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开发，它的驱动模式是什么？
现在做项目，一般有三种开发模式：
MiniFramework更倾向于页面驱动和数据驱动，而且MiniFramework很容易将Model Driven Design转化为实际可运行代码。象银行系统，底层多是C写的，并没有对象的概念，但并不是说没有领域模型。
MiniFramework现在很完善了吗？
还是beta阶段，但是我认为对一般的项目应该够用，我已经做了完整的CRUD例子，其中有三表关联，还是有一定复杂性和代表性。
但是，我现在也在思考一个真正的企业级框架，如果说它是1.0版本的话，MiniFramework就是0.1版了，距离还很远。但我大致上思路很明确，除了以上的idea外，我还会加入以下idea和功能：
上面的很多概念并不是来源于MIS系统，但是我想将其思想引入到MiniFramework中，但还要保证MiniFramework的简单、易用。
你也知道，公司都是利润驱动的，MiniFramework对公司提高利润有那些帮助呢？
从上面的“生产率”FAQ我已经解答了部分，现在我要从整个软件生命周期的角度考虑：
但是，在项目开发过程中，一般不建议瀑布模型，因为那样风险太大。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分钟时间。
是什么决定了系统的可维护性和扩展性，也是我现在在思考的问题。
我现在看到两种切实可行的方案：
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代码），而且这样做也不影响系统的可维护性。
我很希望听你仔细从头描述一下你的平台。如：平台的动机、目标；利用你的平台如何实现一个基本CRUD功能等。
我也有类似的经验。Msn你何时在线？
可能是我们的开发环境限制，因为我们这边中大型项目较多，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文件里面都是plain结构，删掉了所有关联，一个中大型项目所有的hbm.xml完全由一个人维护一点也不难。
上面这段话我很认同，所以我也没有采用代码自动生成的方式，我采纳你的建议，是以前你回复的这部分：
非常感谢你的关注和耐心！
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分钟时间。
- cottonBusiness_code.rar (655.5 KB)
- 描述: 包括所有代码，文章在docs目录下。
- 下载次数: 2982
- 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可能有空.
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
我们不仅考虑技术，还要综合考虑管理因素，特别是大型项目。
其实国内的软件开发都是做工程的，但是都用做研究的方式来做事情，陷入技术泥潭，却始终只是跟在别人屁股后面“学习”。
你把它叫做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
我们不仅考虑技术，还要综合考虑管理因素，特别是大型项目。
其实国内的软件开发都是做工程的，但是都用做研究的方式来做事情，陷入技术泥潭，却始终只是跟在别人屁股后面“学习”。
你把它叫做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
学习的地方很多，
但是也有一些不太理解的地方。
想与作者交流一下，OK？？
MSN:maguangjinan@yahoo.com.cn
QQ:8195819
11 楼
zwchen
2007-01-18
想想在这种环境下你会怎么做：你在一家大型IT外包公司，并且你是项目的technical leader，忽然来了一个中型项目，100人月左右，临时调来公司暂时闲着的开发人员，然后期望着这个项目在三个月后上线。
这应该是一个对管理和技术都有挑战性的主题，说说你们的高见吧，先谢谢了！
就说我想到的吧：
1、培训 视成员能力层次，持续的培训，每周三次左右，每次一个半小时；以及对共通出现问题不定时半小时左右讨论和培训
2、做一个简单的集成框架，让人人都容易理解和开发。
3、尽量撇开公司重量级的CMM5，采取一些轻量级的过程管理，如Agile UP
..........
这应该是一个对管理和技术都有挑战性的主题，说说你们的高见吧，先谢谢了！
就说我想到的吧：
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生成
个人觉得手动维护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生成
但感觉这种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，但在某种程度上可以适合一批项目的开发，团队也容易控制。
在前端表现层我用的是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，对于我们同等重要。
我还是很认同一些经典书籍的理论，譬如对我影响很大的两本书：
《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操作给隐藏起来，毕竟开发是一个团队的事情。我想取得技术和成本的一种平衡。
但是，国内真实的项目环境并不是这样，往往精通，或者熟悉Hibernate的都是少数，毕竟中国的软件开发环境大多数是中低端。
另外，我去掉了持久层，只保留的dao helper，是因为，我发现业务比较简单的系统，往往开发人员喜欢在持久层里面写所有的业务，service层只是dao的一个delegate，非常thin。要是这样，我就干脆去掉一层算了，这便是dao helper的由来。
另外，对于一个项目，老板最关心的，不会是技术，而是成本和期限。如果你的团队能力是一个客观水平，除了培训，你怎样设计整合一个框架，让大家都能快速上手，并且减少技术不透明性，减少代码调试时间(Map很容易调试)，可能是一个必须面对的客观现实。
我之所以要将Hibernate复杂关联隐射都去掉，而采用手工，主要就是想降低开发难度，把hibernate操作给隐藏起来，毕竟开发是一个团队的事情。我想取得技术和成本的一种平衡。
4 楼
zwchen
2007-01-15
Lucas Lee 写道
我对你的框架的主要意见在于：你采用代码生成的方式。
这个方式我认为对于开发速度和可维护性的好处很有限。原因在于，如果你修改了自动生成的代码，那么难以再次使用生成代码同时保持改动不被覆盖。对于代码生成，我认为比较合适的是EJB那样不需要程序员维护的自动生成的代码。
这个方式我认为对于开发速度和可维护性的好处很有限。原因在于，如果你修改了自动生成的代码，那么难以再次使用生成代码同时保持改动不被覆盖。对于代码生成，我认为比较合适的是EJB那样不需要程序员维护的自动生成的代码。
上面这段话我很认同，所以我也没有采用代码自动生成的方式，我采纳你的建议，是以前你回复的这部分：
引用
我的建议还是一样，"元数据"化。
你看你的代码，都已经整理得比较清楚了，我估计你再写几个模块，代码模式、结构基本都一样。(我也经过这么一段时间，开始觉得很规整，有点软件工程的意思，但后来觉得枯燥，总是在重复。)那么究竟哪些地方不同呢？无非就是表名、字段、字段类型等等这些“元数据”是不同的，那么将这些元数据抽取出来，单独定义，那么剩下的不就是完全一样的东西么？那么不就能做成一个统一的唯一的程序么？
就是说，一个支撑、解释程序，加一些元数据，可以构成一套完整的系统。
我这里还没有提及灵活性、扩展性的部分，但至少就简单的数据维护部分，上述思路是适用的。
你看你的代码，都已经整理得比较清楚了，我估计你再写几个模块，代码模式、结构基本都一样。(我也经过这么一段时间，开始觉得很规整，有点软件工程的意思，但后来觉得枯燥，总是在重复。)那么究竟哪些地方不同呢？无非就是表名、字段、字段类型等等这些“元数据”是不同的，那么将这些元数据抽取出来，单独定义，那么剩下的不就是完全一样的东西么？那么不就能做成一个统一的唯一的程序么？
就是说，一个支撑、解释程序，加一些元数据，可以构成一套完整的系统。
我这里还没有提及灵活性、扩展性的部分，但至少就简单的数据维护部分，上述思路是适用的。
非常感谢你的关注和耐心！
3 楼
LucasLee
2007-01-15
我对你的框架的主要意见在于：你采用代码生成的方式。
这个方式我认为对于开发速度和可维护性的好处很有限。原因在于，如果你修改了自动生成的代码，那么难以再次使用生成代码同时保持改动不被覆盖。对于代码生成，我认为比较合适的是EJB那样不需要程序员维护的自动生成的代码。
另一个方面，代码生成相对于动态解释而言，主要的优势在于性能比较高。但高了多少？我认为还是比较有限的。无非就是把很多动态的变量，固定在代码里了，比如字段名，动态解释肯定是从配置文件里读到内存里，存在一个变量里，而代码生成就是一个固定的字符串。
所以从这个角度，你基本上没有采用或者考虑过我的建议。当然这只不过是我的建议而已。
如果采用动态解释，（即运行时按元数据执行相应的操作，如CRUD），那么hibernate,spring，JSTL等流行的框架和技术很可能无法适用，这也是你难以取舍的地方，一般人都希望将最流行的框架用起来，否则有被主流抛弃之风险，这也是我之前面临的困境，不过我仍然坚持了动态解释的路子。
一个CRUD 1百行代码固然不错，不过就我的元数据编程观点来看，是远远不够的。就基本的、惯用模式的CRUD，我觉得应当只给出表名、字段名、字段对应的组件即可完成。当然，对于更复杂的情形，依然允许通过定制各种属性，接入Java程序来实现。
给你提一个方向，试想，先抛弃你提到的所有的框架，如果他们给了你困扰的话，不要为了用它而用；然后想想我上面说的目标是否能实现? 我觉得不是那么难的。也欢迎其他人来思考这个问题。
这个方式我认为对于开发速度和可维护性的好处很有限。原因在于，如果你修改了自动生成的代码，那么难以再次使用生成代码同时保持改动不被覆盖。对于代码生成，我认为比较合适的是EJB那样不需要程序员维护的自动生成的代码。
另一个方面，代码生成相对于动态解释而言，主要的优势在于性能比较高。但高了多少？我认为还是比较有限的。无非就是把很多动态的变量，固定在代码里了，比如字段名，动态解释肯定是从配置文件里读到内存里，存在一个变量里，而代码生成就是一个固定的字符串。
所以从这个角度，你基本上没有采用或者考虑过我的建议。当然这只不过是我的建议而已。
如果采用动态解释，（即运行时按元数据执行相应的操作，如CRUD），那么hibernate,spring，JSTL等流行的框架和技术很可能无法适用，这也是你难以取舍的地方，一般人都希望将最流行的框架用起来，否则有被主流抛弃之风险，这也是我之前面临的困境，不过我仍然坚持了动态解释的路子。
一个CRUD 1百行代码固然不错，不过就我的元数据编程观点来看，是远远不够的。就基本的、惯用模式的CRUD，我觉得应当只给出表名、字段名、字段对应的组件即可完成。当然，对于更复杂的情形，依然允许通过定制各种属性，接入Java程序来实现。
给你提一个方向，试想，先抛弃你提到的所有的框架，如果他们给了你困扰的话，不要为了用它而用；然后想想我上面说的目标是否能实现? 我觉得不是那么难的。也欢迎其他人来思考这个问题。
2 楼
vaja
2007-01-15
直面现实，佩服楼主，研究一下。
1 楼
giscat
2007-01-15
发表评论
-
一个优秀的Java企业应用框架的设计和实现
2013-10-25 17:43 52一个优秀的Java企业应用框架的设计和实现： http:/ ... -
一个Java框架引发的思考：语言、框架、范式转换和软件生产力
2011-09-10 13:26 3714前几天，iteye上的pojo同学，发来了他四年前写的一个框架 ... -
电子商务网站，前后台是否该分离？
2011-08-21 12:44 8058做电子商务网站，一般 ... -
Java源码阅读的真实体会
2011-08-20 19:51 25837刚才在论坛不经意间，看到有关源码阅读的帖子。回想自己前几年，阅 ... -
我理解的互联网应用和企业应用开发
2011-07-12 12:01 3194前段时间，我写过一篇该主题的博客，但写完了，我觉得还是没有谈到 ... -
一个在读学生的疑问及我的回复
2011-06-24 11:39 3115我经常收到类似的站内信，然后花上半个来小时回复(我摆文字真的非 ... -
一位技术人员成长历程
2010-05-26 15:52 126454、坚持了第一个月，再坚持半年，以后的学习速度越来越快，你离 ... -
Java虚拟机技术总结(07年写的,原JavaEye精华帖)
2010-04-17 11:15 8385原文：IBM WebSphere Application Se ... -
IBM WebSphere Application Server 诊断和调优(07年写的,原JavaEye精华帖)
2009-12-19 11:07 8302这是上篇文章的续篇， ... -
JBPM源码浅析
2007-09-13 15:04 16539离职啦，工作交接中， ... -
JBPM阶段性工作总结
2007-09-12 15:20 14477快要离职了，工作交接 ... -
AIX学习总结笔记一
2007-07-03 18:07 8506公司项目用到AIX和Websphe ... -
软件开发的一点感想
2007-06-29 10:53 6110这两天，遇到工作中的两个小问题，加深了我以前对软件开发的看法。 ... -
Java线程安全系列（1）--Servlet线程安全
2007-06-16 23:19 13311刚才search的时候，竟然 ... -
从分布式系统的角度看REST
2007-05-28 20:37 3593原帖：http://www.iteye.com/t ... -
也说说项目成败、企业信息化
2007-05-19 15:25 2621这篇文章是我对nbsp同学 ... -
读HSQLDB的源码想到的
2007-05-17 10:36 9295昨天在论坛看到一篇讨 ... -
Web Services开发体会和项目教训
2007-04-21 14:42 52959去年，在一个大型项目( ... -
Seasar Framework介绍(一)
2007-04-21 00:18 10920近段时间，给公司一项 ... -
Struts的html:options 标签内幕
2007-04-20 18:14 7959最近用一个在日本很流 ...
相关推荐
刘嘉怡.中期检查.doc
内容概要：本文详细介绍了如何使用COMSOL Multiphysics进行热电效应仿真的全过程。首先解释了热电效应的基本概念及其应用场景，如手机充电发烫、吹风机温度升高等。接着，通过具体实例展示了如何在COMSOL中建立热电模型，包括选择合适的物理场（焦耳热和热电效应）、设定材料属性（电导率、导热系数、塞贝克系数）、绘制几何形状以及设置边界条件。文中还提供了详细的MATLAB代码片段用于自动化建模流程，涵盖求解器配置、网格划分、后处理等方面的技术细节。此外，作者分享了一些常见问题的解决方案，如求解器不收敛、网格畸变等。 适合人群：对热电效应感兴趣的科研人员、工程技术人员及高校学生，尤其适用于有一定COMSOL和MATLAB基础的学习者。 使用场景及目标：帮助读者掌握热电效应的基本原理和COMSOL仿真技能，能够独立完成从模型构建到结果分析的完整流程。目标是提高热电转换系统的效率，优化设计参数，探索新材料的应用潜力。 其他说明：文章不仅提供了理论指导，还包括大量实战经验和技术技巧，有助于解决实际建模过程中遇到的问题。
内容概要：本文深入探讨了汽车内外饰模具设计的关键要素，涵盖分型面设计、斜顶和滑块的应用、模架选择以及顶出系统的配置。针对每个部分，不仅提供了理论指导，还辅以Python、MATLAB等编程语言的实际代码示例，帮助理解和实施具体设计方案。例如，分型面设计强调了如何根据产品结构和外观要求确定最佳分型面位置；斜顶和滑块部分讨论了不同类型及其应用场景；模架和顶出系统则关注于结构稳定性和顶出效果的优化。 适合人群：从事汽车模具设计的专业人士，尤其是希望深入了解内外饰模具设计细节的新手设计师和技术人员。 使用场景及目标：适用于汽车内外饰模具设计项目，旨在提高模具设计的精度和效率，减少试错成本，确保产品质量。通过学习本文提供的技术和实践经验，能够更好地应对实际工作中遇到的各种挑战。 其他说明：文中提到的代码示例和经验公式均来源于实际工程案例，具有较高的参考价值。同时，作者还分享了许多宝贵的行业经验和技巧，有助于读者快速掌握模具设计的核心技能。
python3.10以上 可安装pyside6（类似pyqt），具体安装操作步骤
内容概要：DeepSeek AI是由杭州深度求索人工智能基础技术研究有限公司于2025年1月20日发布的深度探索AI技术。它具有多模态能力、多语言支持、长上下文理解、领域垂直优化、开源特性等多项技术突破，支
IIS配置phpweb服务器所需VC_redist.x64.rar
云南移动5G-A网业战略发展探讨 -创新领航，千帆竞发，共同迈入5G-A新时代.pptx
本文描述了如何使用C#基于OpenCvSharpe实现模版匹配功能，其中实现了下功能： 1、图像加载； 2、模版加载、绘制、保存功能； 3、模版匹配功能。
内容概要：本文档汇集了CSci 235软件设计与分析II课程中关于数据结构的面试题，由Stewart Weiss教授整理。文档涵盖了广泛的数据结构主题，包括但不限于链表（如单链表、双向链表、循环链表）、二叉树（如二叉搜索树、最小高度二叉搜索树）、栈、队列等。每个问题都旨在考察求职者对不同数据结构的理解及其应用场景。例如，选择合适的数据结构实现手机通讯录功能，或设计支持撤销功能的文本编辑器。此外，文档还探讨了复杂度分析（Big-O表示法），以及如何优化特定操作的时间复杂度。最后，文档提供了额外的学习资源链接，帮助求职者进一步准备面试。 适合人群：计算机科学专业的学生或有志于从事软件开发工作的求职者，特别是那些希望在技术面试中表现优异的人士。 使用场景及目标：①理解并掌握常见数据结构的基本概念和特性；②学会根据不同场景选择最合适的数据结构；③掌握常见数据结构操作的时间复杂度分析；④为技术面试做充分准备，提高面试成功率。 其他说明：文档中的问题不仅限于理论知识，还包括实际编码练习，建议读者在学习过程中动手实践，以加深理解和记忆。同时，文档提供的额外资源链接可以作为扩展阅读材料，帮助读者更全面地掌握相关知识。
Matlab领域上传的视频是由对应的完整代码运行得来的，完整代码皆可运行，亲测可用，适合小白； 1、从视频里可见完整代码的内容 主函数：main.m； 调用函数：其他m文件；无需运行 运行结果效果图； 2、代码运行版本 Matlab 2019b；若运行有误，根据提示修改；若不会，私信博主； 3、运行操作步骤 步骤一：将所有文件放到Matlab的当前文件夹中； 步骤二：双击打开main.m文件； 步骤三：点击运行，等程序运行完得到结果； 4、仿真咨询 如需其他服务，可私信博主； 4.1 博客或资源的完整代码提供 4.2 期刊或参考文献复现 4.3 Matlab程序定制 4.4 科研合作
帆软本地打印插件FinePrint 8.0版本，适用于FineReport8
内容概要：本文介绍了密歇根大学EECS 461课程——嵌入式控制系统的核心内容及其发展背景。课程旨在教授学生嵌入式控制系统的理论与实践，包括传感器和执行器接口、实时性能和安全要求、混合行为系统、分布式控制网络等方面的知识。文中特别强调了现代汽车作为嵌入式控制系统的典型应用，从1977年到2019年间，汽车技术经历了从模拟控制到微处理器控制的巨大变革，如今的汽车具备了更高效、更环保、更安全的特点。课程还涵盖了S32K144微控制器的开发环境、实验室练习（如数字I/O、PWM信号生成、虚拟墙模拟等）以及自动代码生成工具的使用。 适合人群：具备一定编程基础，特别是对嵌入式系统感兴趣的本科生和研究生，尤其是电气工程、计算机科学专业的高年级学生或硕士生。 使用场景及目标：①了解嵌入式控制系统的基本概念和发展历程；②掌握嵌入式控制系统的设计方法和技术手段，如实时操作系统、中断处理、网络通信协议（CAN）等；③通过实际项目操作，熟悉嵌入式硬件平台和开发工具链的应用。 其他说明：随着汽车行业向智能化、自动化方向发展，对于能够开发复杂嵌入式软件的人才需求日益增长。EECS 461不仅为学生提供了扎实的技术训练，也为他们未来的职业发展打下了坚实的基础。此外，课程还反映了跨学科教育的重要性，鼓励学生打破传统学术界限，培养解决实际问题的能力。
内容概要：本文详细介绍了如何利用C#与Halcon联合编程构建高效的视觉几何定位与测量框架。主要内容涵盖模板创建与匹配、圆测量、数据持久化以及图像采集等方面的技术细节。首先，通过创建形状模板并进行匹配，实现了工件的精确定位。接着，针对圆形物体的测量，提出了动态ROI绘制、亚像素边缘提取和稳健圆拟合的方法。此外，还讨论了模板管理和图像采集的最佳实践，确保系统的稳定性和高效性。最后，强调了Halcon对象的内存管理和错误处理机制，提供了实用的优化建议。 适合人群：具备一定编程基础，尤其是对C#和Halcon有一定了解的研发人员和技术爱好者。 使用场景及目标：适用于工业生产线上的自动化检测设备开发，旨在提高工件定位和尺寸测量的精度与效率。主要目标是帮助开发者掌握C#与Halcon联合编程的具体实现方法，从而构建稳定可靠的视觉检测系统。 其他说明：文中提供了大量实战代码片段和调试技巧，有助于读者快速理解和应用相关技术。同时，作者分享了许多实际项目中的经验和教训，使读者能够避开常见陷阱，提升开发效率。
内容概要：本文深入探讨了DeepSeek AI的独特优势及其在全球AI领域的影响力。DeepSeek由中国深度求索公司开发，自2025年1月20日发布以来，凭借其卓越的性能和独特优势迅速吸引了全球关注。其核心优势包括：1) 极致成本效率，如低成本训练和高效推理；2) 强大的推理能力，涵盖多领域表现优异
php连接sqlserver之VC_redist.x64.exe
内容概要：本文详细介绍了利用Matlab/Simulink进行异步电动机交流调速系统的仿真实验，主要探讨了两种控制方式：恒压频比（V/F）开环控制和转差频率闭环控制。文中不仅提供了具体的数学模型和代码片段，还展示了不同控制方式下的仿真结果对比，包括转速响应、电流波形和谐波含量等方面的表现。此外，文章深入讲解了SVPWM（空间矢量脉宽调制）的应用，强调了其相对于传统SPWM的优势，并给出了详细的参数调整技巧和注意事项。 适合人群：从事电机控制系统设计的研究人员和技术人员，尤其是对Matlab/Simulink有一定基础并希望深入了解异步电动机调速系统的人群。 使用场景及目标：适用于需要进行电机控制算法开发和优化的场合，旨在帮助读者掌握异步电动机调速的基本原理和具体实现方法，提高仿真的准确性和效率。 其他说明：文章通过丰富的实例和图表，生动地展示了各种控制策略的特点和效果，有助于读者更好地理解和应用相关理论。同时，文中提供的调试技巧对于解决实际工程中的常见问题非常有帮助。
内容概要：本文详细介绍了如何利用Matlab进行电动汽车等速工况续驶里程的仿真。首先解释了等速工况的概念及其重要性，接着展示了具体的参数设定，如车辆质量、风阻系数、电池容量等。然后深入探讨了核心算法，包括阻力计算、功率需求、能量消耗以及SOC（剩余电量）的变化过程。文中特别强调了一些常见的陷阱和注意事项，如单位换算错误、电机效率的动态变化等。最后，通过可视化工具展示了仿真结果，并讨论了可能的改进方向，如引入NEDC工况循环和其他动态因素。 适合人群：新能源汽车专业的学生、研究人员以及对电动汽车仿真感兴趣的工程师。 使用场景及目标：①帮助理解和掌握电动汽车等速工况续驶里程仿真的原理和方法；②提供详细的代码实现和注释，便于学习和修改；③用于课程设计、毕业设计或其他研究项目。 其他说明：本文不仅提供了完整的Matlab代码，还包括详细的参数说明和常见问题解析，确保使用者能够顺利运行并理解整个仿真过程。同时，作者还分享了许多实践经验，有助于提高仿真的准确性和实用性。
【定稿】桂林电子科技大学第七届大学生思政课社会实践优秀成果展示活动实施方案 (1).zip
内容概要：本文详细介绍了使用Maxwell 16.0和ANSYS 2020进行直线感应电机瞬态磁场仿真的方法和技术要点。首先强调了建模前的准备工作，包括初级线圈布置、次级导体材料选择、气隙宽度等参数的确定。然后针对Maxwell 16.0用户，讲解了坐标系的选择（笛卡尔坐标系）、初级绕组绘制、运动参数设置、网格剖分优化以及边界条件的正确配置。对于ANSYS 2020用户，则着重讲述了如何利用Maxwell模块建立模型并在Mechanical中进行电磁力耦合分析，包括参数化扫描设置、气隙厚度扫描、磁密云图动态更新等技巧。此外，文中还分享了许多实用的经验和注意事项，如避免常见的参数设置错误、提高仿真精度的方法、处理推力波动等问题的具体措施。 适合人群：从事电机设计与仿真的工程师、研究人员，尤其是有一定Maxwell和ANSYS使用基础的技术人员。 使用场景及目标：帮助用户掌握直线感应电机瞬态磁场仿真的全流程，确保仿真结果的准确性，提升工作效率。具体应用场景包括但不限于新电机设计验证、现有电机性能优化、故障诊断等。 其他说明：文中提供了大量具体的命令和脚本示例，便于读者直接应用到实际工作中。同时，作者结合自身丰富的实践经验，给出了许多宝贵的建议和警示，有助于读者避开常见陷阱，顺利完成仿真任务。
内容概要：本文详细介绍了如何在Matlab Simulink中构建交流异步电机的矢量控制模型及其SVPWM调制方法。首先解释了坐标变换（如Clarke和Park变换）的基本原理，并提供了具体的实现代码。接着讨论了双闭环控制策略，即电流环和速度环的设计与参数整定，强调了PI控制器的抗饱和处理以及速度环带宽的选择。对于SVPWM部分，文章对比了几种不同的调制算法，推荐了一种改进的七段式算法，提高了电压利用率并降低了谐波含量。此外，文中还分享了许多实际调试过程中遇到的问题及解决方案，如启动电流冲击、低频振荡等。 适合人群：从事电力电子、电机驱动系统设计的研究人员和技术工程师，尤其是对矢量控制和SVPWM感兴趣的初学者。 使用场景及目标：适用于需要深入了解交流异步电机矢量控制原理及其实现方法的人群。目标是在掌握理论基础上，能够独立搭建并优化Simulink仿真模型，从而提高实际应用中的性能表现。 其他说明：随文提供的工程文件包含了完整的模型和详细的参数整定表格，便于读者进行实践操作。同时，作者还提供了一些实用的小贴士，帮助避免常见的错误和陷阱。