zjsun
2005-03-28 20:36
我来简单介绍一下我们的平台(我们称他为“业务构建平台”):

简单的说是一个快速开发平台,开发过程(平台提供的工具):

1、数据建模:数据库实体表、视图、关系等的建立

2、应用建模:通过上面定义的数据模型,自动生成应用JSP页面,提供数据的增、删、改、查、校验、动态感应提示等功能,并提供一系列二次开发接口:数据展现处理、数据操作处理、数据保存处理等。对于查询,对所有生成的JSP页面已经集成了通用接口,只需要向这个JSP提交(submit)相应的参数即可。

3、权限建模:定义who(角色)对resource(数据)能够进行哪些操作(action)。目前只实现了数据权限的控制(包括数据的查看、修改、新增、删除的控制),以后需要扩展到上层次的权限控制,如:功能操作、模块页面级的控制

当然,我们还在业务构建平台上基础上还有一套工作流平台,用来解决业务协作问题,还有报表数据分析平台(目前与业务构建平台关系不大,由于历史遗留原因)

平台越做越大,代码越来越乱,经历了“几代人”,我是唯一支撑到现在的成员,曾经想重整现有代码,迫于用户以及项目实施的压力,一直没有敢开刀,功能还不是很完善,新的需求又开始堆积,真不知该如何是好?

zjsun
2005-03-28 20:39
>对于查询,对所有生成的JSP页面已经集成了通用接口,只需要向这个JSP提交(submit)相应的参数即可。

包括切换同一实体对象不同的维护模式、过滤条件、排序、分页调整、自定义列显示等

yuxie
2005-03-29 16:34
业务构件平台……

国内一些电信软件开发商使用了一个号称 银弹 的面向构件的开发平台,叫做EOS。这个东东设计了一个基于J2EE的框架,把常用的操作封装成一个个的构件,并同时有相应的IDE支持。系统在运行时通过XML的配置定义数据结构和业务流程,调用其写好的构件,输出XML数据流,并通过tag展现到web层。实际工作中这个东西确实有方便的地方,加速了系统的开发过程。不过最大的问题来了,有了这个东西之后,所有的系统分析和设计就跟OO无关了,所有工作只要围绕数据库实体模型来就OK了,调用个数据库操作的构件(比如执行sql的构件,写好sql语句),输出结果……用的过程感到很失落……

没有了OO,实际应用过程中自然有好多的问题,构件复用粒度太大,造成灵活性很低,而实际开发速度好像也快不了多少。这个号称 银弹的东西自然被骂了好多,但是它确实能满足我们的需求,似乎也能满足楼主说的那些需求。

这里我就不明白了,对于这么一个构件平台,是不是应该加上一条需求:为了加快开发人员上手,加快开发速度,构建平台应该是面向数据库操作的,而不是面向对象的?

netcom19
2005-03-29 18:39
凌科软件的elinkBSP就是你说的这样的平台,只要设计人员能想到的就能迅速的实现。www.elingke.com 上有详细介绍

taikeqi
2005-03-30 10:22
奉劝你们,不要做这个层面上的事情。找个现成的,得到验证的框架,或者去找普元公司。或者去找IBM公司,依托那些个大公司的技术。不就是花点钱吗?!把自己的精力集中到业务和服务上来。

zjsun
2005-03-30 12:47
普元的EOS我们也曾经试图协作和商讨过,但正像yuxie所说的,偏离了OO,更像面向过程,而且对于开发人员来说,上手不是那么简单,从某种程度来说,更加复杂,而且经过我们一段时间的评估,中间还有一些常见的企业级问题不能解决。当然,EOS能够发展到现在,我已经相当佩服,包括一种新的理念和他们的投入。

诸如IBM这类企业,他们是做底层平台的,虽然也有一些业务倾向,但毕竟不是专业,而我们需要的是他们的底层支撑,我们要把业务层专业化。

taikeqi
2005-03-31 10:41
看来我对这个问题认识还是不够仔细。谢谢zjsun的回复

LoseSky
2005-03-31 12:10
其实这样的平台构件早就出来了,但是出于中国的实际情况,无法在短时间内做进一步推广.

建议登陆 http://www.mybo.org/

http://www.mybo.com.cn/

你所提出的几点问题,在这个平台中已经非常成熟了.

nihao
2005-03-31 23:08
业务平台倒没见过好用的。

到见过一个工作流平台是我见过的最接近大家所谓的“平台”了。

就是这个东冬:Joinwork,与J2EE各层面结合的不错,也支持OO。

比较佩服他们敢于直接让别人下载使用,网上的演示版本也是完整特性展示。国内公司能做到这一点的不多。

nihao
2005-03-31 23:14
>

>

> 建议登陆 http://www.mybo.org/

> http://www.mybo.com.cn/

>

> 你所提出的几点问题,在这个平台中已经非常成熟了.

刚上去看了看,除了售前宣传资料,看不到实质内容。演示站点也进不去,估计不柞样。看都不敢给人看,呵呵。

zjsun
2005-04-01 14:20
申明:我所指的是“业务构建”,而非“业务构件”

避免大家概念混淆。

boboku
2005-04-05 17:25
我和我的同事在2001年和2002年之间干过和zjsun类似的事情,

后来失败了,

有各方面的原因,

其中最主要的就是管理方面的原因和开发人员自身素质不够,

当时我们实现的是可视化数据建模,

自动生成数据操纵组件比如EJB,

当时用的是Jonas调试,

根据图形化的工具编辑显示用的Xml,

自动生成jsp,

自动生成各种“模”的修改事件方法,

能够支持将很简单的脚本语言编译成Java代码,

代码包括中间层的处理和前台事件的处理,

还包括事务的处理,

。。。。。。

做这个东西真的比较麻烦,

后来也见识过不少其它公司做的类似于这种目的的产品,

但是都不太理想,

现在埋头做这个产品不行,

非得在多年的大量实际开发经验中获得丰富的认识才能够更好开发出有用产品,

光有注重于对各种开发思想的研究而没有大量实战经验不行,

光埋头苦干不注重新的思想吸收也不行,

真的需要一定的功力,

对于技术方面来说,

我感觉你可能要从各种业务功能实现中跳出来,

变成各种规则的定义和解释执行,

还有就是丰富的接口定义,

另外建议你先从简单点的做起,

不要试图一下子整个平台能够完美建成,

还需要一定时日的,

希望你能够成功啊!

etenant
2005-04-07 12:34
_对于这么一个构件平台,是不是应该加上一条需求:为了加快开发人员上手,加快开发速度,构建平台应该是面向数据库操作的,而不是面向对象的?

这位哥们分析最透彻。

个人看还是方法论方面的问题。既然是面向对象,也须知道对象的不稳定性。用哲学术语讲,就是形而上的概念向来都是在不断超越与被超越。

为一个单纯目的“加快上手,加快开发速度”而搭建的平台,自然有其不足之处。依靠它来解决它专长之外的问题,正如为搞阶级斗争全盘接受毛思想的人突然被要求去搞存在主义一样境遇尴尬。

jjsspp2005
2005-04-12 17:29
老BanQ的回答文不对题,瞎扯!

J2EE能符合楼主的这些条件吗。

不要总是装成一个J2EE专家的样子。

cxj_2000
2005-04-13 17:07
> 业务构件平台……

> 国内一些电信软件开发商使用了一个号称 银弹

> 的面向构件的开发平台,叫做EOS。这个东东设计了一个基于J

> EE的框架,把常用的操作封装成一个个的构件,并同时有相应

> IDE支持。系统在运行时通过XML的配置定义数据结构和业务?> 程,调用其写好的构件,输出XML数据流,并通过tag展现到we

> 层。实际工作中这个东西确实有方便的地方,加速了系统的开

> ⒐獭2还畲蟮奈侍饫戳耍辛苏飧龆髦螅械南低

> 分析和设计就跟OO无关了,所有工作只要围绕数据库实体模型

> 淳OK了,调用个数据库操作的构件(比如执行sql的构件,写

> sql语句),输出结果……用的过程感到很失落……

> 没有了OO,实际应用过程中自然有好多的问题,构件复用粒度

> 螅斐闪榛钚院艿停导士⑺俣群孟褚部觳涣硕嗌佟U

> 个号称

> 银弹的东西自然被骂了好多,但是它确实能满足我们的需求,

> 坪跻材苈懵ブ魉档哪切┬枨蟆?> 这里我就不明白了,对于这么一个构件平台,是不是应该加上

> 惶跣枨螅何思涌炜⑷嗽鄙鲜郑涌炜⑺俣龋菇ㄆ教ㄓ

> 该是面向数据库操作的,而不是面向对象的?

这玩意速度快吗?如果象电信那种业务复杂的东东,估计读一次XML都要半天了。

猜你喜欢
5Go 上一页 1 2 3 4 ... 5 下一页