如何快速高效的完成一个3层架构的应用系统的开发

03-06-16 link
现在3层架构的应用的需求越来越多。我个人认为利用java技术去实现这方面的应用是最好的。但是目前java也没有一个很好的工具去实现这方面的应用。(应该讲是快速的实现这方面的实际应用)不管如何,开发人员如果选择了java。他就要面对诸如:安全、日志、数据库的连接、管理用户生存、负责业务分发,控制业务并发负载、报表处理.......。有人讲jbuild。对,这个工具是不错。但是他还是没有远远达到去“快速”开发一个基于中间件技术应用的实际项目。它还是会让编程人员去面对上面提到的诸如此类的问题。有人可能会笑我,因为程序员如果不去熟悉这些技术细节,那还写什么程序。

但是我认为程序员还要分几等:系统级的开发、应用级的开发。实际上微软在这方面做的真的很好。他提供的.net,VB开发工具就是让程序员去多多关心应用级的开发。也就是讲开发人员只要去关心最终用户业务逻辑的开发,而少做系统方面的实现。

回过头,看看国内很多企业他们目前用的都是基于以前c/s架构的网络产品。我不是讲c/s架构不好。举个例子:一个保险公司,它在全国有很多的子公司。各个子公司与子公司的资源共享,子公司与母公司的资源共享,如何实现?以前用基于c/s架构的软件产品不论从公司的对硬件的投资、技术人员的投资、更甚公司运作的效率、母公司对子公司的控制来讲。他们都有充分的理由去选择基于b/s架构的软件产品。但是就是这种3层架构应用的复杂性,对程序员技术的高要求,导致了很多项目的实施是不如人意。如何解决这个问题?这就是摆在我们这些java程序员面前的一个比较严峻的问题。因为必尽我们是希望技术转化为生产力。

那么如何实现快速开发呢?我希望大家能多多提意见

我现在用jdevelop。感觉很好,但是我想把我自己做的相报表自动生成包容进去就不知道如何做了?

同时我也希望大家能够就我前面的观点多多讨论。

2
banq
2003-06-16 13:24
这次JavaOne大会Jboss推出的基于AOP开发的4.0版本就是要实现快速开发的简易性。

N层架构最终会替代C/S,这是潮流,已经不容质疑,C/S技术只用来维护那些老的系统,就象现在的cobol程序员一样。

我曾经写了一篇文章,快速开发J2EE的项目:

http://www.jdon.com/jive/article.jsp?forum=46&thread=7111

当然,复杂的报表没有写进去,我想报表和界面处理有一致性,只要确立好系统所要使用的几种报表样式,以后反复套用就方便多。

因为Java涉及的方面太广,又因为有开放源代码的参与,使的新的思想和架构不断涌现,如果想在这些新思想出现之前就能预见好一些框架,是不现实的,我一直认为 "乱"是活力和自由的另外一种表达词。

我在J2EE实际开发中的每进行一步都问问:这步必须吗?最后总是肯定,是必须的,这些必须的阶段组合起来,就好像形成了J2EE似乎复杂的表面,其实就是.NET,他如果要想达到J2EE这样成熟的应用,这些需要程序员确认设置阶段他都回避不了,就象照相机拍照由光圈和快门组成,手动相机就是记住在日光下一般用125x8的组合,自动相机最多是能自动测试光线,然后告诉你现在是日光模式,用日光模式替代快门和光圈的数字。

但是手动相机不会被抛弃,他一直手专业人士的爱戴,使用手工相机能够最大发挥操作者的才智,能够拍摄出精美绝伦的艺术作品。我想目前的J2EE就是这样一步精致的手动相机。

未来相信,J2EE也会平民化,通俗化,Jboss 4.0的推出就是一个信号。

zhu_am
2003-06-16 16:37
小弟学JAVA才半年,入世不深,还请多多指教,

MAIL:zhu_am@msn.com

link
2003-06-16 16:42
""乱"是活力和自由的另外一种表达词"这句话很经典。我想不论初学java还是搞了几年了,都会认为java中的技术很“乱”。但这不是坏事,这也就是为何C#永远无法和java相抗衡的其中一个原因吧。

我看了banq的那篇文章。还是我讲的,在真正的应用中这些是远远不够的。我们曾经通过一个structs构造了一个很简单的系统平台,一共操作数据库中40张表。如果你还是通过手动去写jsp、action、actionform、xml配置、

连接db引擎,那你没有几天的时间是搞不定的。为何这么慢,我分析了一下,就是多了很多重复劳动。因为很多代码的系统框架逻辑是一样的,只不过业务逻辑不同而已。所以我们做了模板,让程序自动生成。几天的工作量真正做到的几个小时的工作量。

实际上做出一个好的基于中间应用服务器的中间件框架,加上代码的自动化生成就能很好的加速不同项目的开发。实际上JSP,SWING,报表,中间业务逻辑的测试程序都是能自动生成。而我们所要做的就是通过新技术,新思想不断的去完善你的中间件框架。

我想“精致的手动相机”是专业人士,发烧友搞得玩艺。而要让大众都去接受,就必须的一台好的“自动相机”。所以“精致的手动相机”的发展应该带动着“自动相机”的不断进步。到那时,我想.NET不会有什么人在去用了吧。

jd2bs
2003-06-16 16:58
java还是更适于一些大型,超大型项目

在中小型项目,特别是短平快项目上劣势很明显:框架过于复杂,门槛较高.所以比较昂贵,很多人自然就选择.net了:)

iceant
2003-06-16 18:11
that's right.

模板技术是很重要的重用技术。但是必须是可方便定制的模板技术。

我也为自己写了一些开发工具,主要是完成重复性的工作,但是一个人的力量是限的,我都觉得有很多地方需要改进,这样生产力可以更大一步的提高,不过愿意付出实际行动的人太少,很多人都只是在等着吃现成的,并不想自己动手去解决问题。

框架的应用应该由模板或代码生成工具来辅助。这一点我坚信不移,这也为框架带来了应用上的难点。你不能不花时间来熟悉框架,只会用用工具,并不能发挥框架真正的潜力,如果脱离了对框架细节的了解,人也将成为生产线上的一个工具。就是所谓的"程序女工"。

想不到这里有这么多人喜欢摄影,我个人最喜欢"哈苏"和 FM3/FM2A,特别是"哈苏",经历了这么多年,它的接口设计得如些美妙,让人看到了软件设计中 OO 思想的精化。多年过去了,但是这些手动相机却是如此经典,即使在自动相机如此流行的今天,专业摄影用的还是这些手动相机。

想要做专业摄影,成相原理,光圈与焦距以及胶卷速度对成相的影响,这些方面都需要了解。如何测光,也需要了解,拿拍雪景来说,对雪测光,拍出来的雪将会是泥灰色的,而对陆地等暗处测光,将会呈现比较精确的白色。

所以,先要爬,再走,最后跑... 基础还是很重要的。

说这些,只是希望新手不要太盲目地追求开发效率,我承认类似 Delphi,CBuilder 这样的开发工具,在一定程度确实不需要写什么代码就能完成一个绚丽的小工具,但你也就只会这些而已了。

zhangpiwang
2003-06-16 21:25
bang的文章中的cmp连接mysql

我没有做过,用的是mysql的什么版本,她不是不支持tansaction么,cmp怎么行

jiangxi
2003-06-17 17:09
我们小组现在准备开发一个小型ERP(下属公司使用)10个左右客户端,LAN,语言是java,数据库是orcle。使用C/S结构(领导一定要用),MVC框架,不用任何服务,完全运行于JVM。不知道使用何种框架合适(想法是将ofbiz的View改为Swing),是否可行!如不能,应该怎么去做? (本人认为只用JVM,不采用J2EE的话,速度会奇慢,甚至不能运行,性能会奇差)。这是我现在面对的事实,只是我的想法得不到证实,请各位多多指点,多多论证。

KillerMan
2003-06-17 17:50
解决的思路很简单,就是做平台,B/S的三层应用逻辑还是很简单的。可以做成完善的开发平台。

平台对底层的如数据源操作等进行封装,形成一个个的插件,然后开发针对这些插件的可视化配置工具。

再此基础上进行另一层次的封装,如封装出一个BBS控件,可以可视化的配置。

各个插件之间通过消息进行通信,支持工作流定制。程序的框架使用过滤器模式,每个插件支持标准的输入接口和标准的输出结构。

托普的erp就是走的平台的思路。不过做的要小儿科一些。

Arbow
2003-06-17 18:19
MySQL的4.0.13版本已经支持事务

Jevang
2003-06-17 23:26
Jingxia,

My suggestion may not sound popular: don't simply rule out C/S architecture design, in many cases, it's the right way to do things. Assuming interaction at data layer make more sense between large modules and among users.

-Jevang

yyanghhong
2003-06-18 07:15
CS和BS模式相比,不是一个更新一个的问题, 而是各有各的领域, BS分发维护方便, 资源共享简单,但他可实现的客户介面功能过于简单,难以实现复杂需求,数据传输环节过多, 造成性能低下 , 谁见过真正web base的ERP系统。

另外,关于.net和java, 对于web开发,也是很难说清谁更有前途, java的中间件产品比较成熟, 加上unix平台稳定。这是.net需花时间追赶的。 但java web前端开发效率,却不理想, struts只是实现了front controler和taglib机制,类似asp.net 里web form的java server face 基本上没可用的平台。无法和基于可视化构件的web form相比。 我认为这是由于java GUI开发上的不足造成的。java的平台无关性, 对操作系统的消息事件处理无法达到桌面程序效率上的要求。从根本上来说,.net和java的前途是跟操作系统的前途联系在一起的。

yyanghhong
2003-06-18 07:32
对于模板和代码生成, 这只能加块开发初期的效率, 对日后修改和维护

反而不利,比较ms的mfc和delhi的vcl就知道了。 真正加块开发效率的方法是model驱动技术, 在这方面, borland作的最好

jiangxi
2003-06-18 08:50
谢谢各位老兄的答复。 sinio_feng老兄,能否介绍详细一点或给点资料,my E-MAIL:lizj1023@163.net。谢谢。java GUI确实有点低能,为确保移植性,它连和EJB交互的能力都让限制了,看样子OFBIZ是用不上了,还得从零开始。不过缺少中间件的支持(如池等),系统是不是会很低效?

raynix
2003-06-18 11:38
> 谁见过真正web base的ERP系统。

请参考PeopleSoft 8.0

猜你喜欢
3Go 1 2 3 下一页