架构问题

05-02-05 ouhua
公司决定开发新的架构,采用struts,ejb,hibernate,我有一些问题想请教各位:
1.如何实现快速开发
2.如何降低维护代价
3.采用JBoss,JBuilder是否可行
公司在这方面缺乏经验,以前做了一个架构,但维护代价有点高

banq
2005-02-05 21:23
你们以前的架构是什么?能否一说?

ouhua
2005-02-06 10:37
以前的架构的主要问题就是在O/R Mapping方面,公司开发了一个代码生成器,可以根据表或视图生成相应的java文件和jsp文件,java文件包括一个业务逻辑文件,一个数据访问逻辑文件,一个java object。这个架构开发速度还比较快,但维护起来太麻烦了,增减字段改起来很麻烦,而且数据存取文件里的函数太大,sql语句太长,再加上需求变更频繁且变化幅度大,整个架构难以适应这种变化,业务逻辑也得不到重用。公司是做行业ERP的,新架构的目标就是为开发人员提供一个技术与业务的平台,但做起来是有相当难度的,首先公司对ejb技术,struts,hibernate,设计模式不太熟悉,其次我们的时间也不算多,但我们真的需要一个优秀架构,我们现在做的项目bug太多,成本太高,开发人员痛苦指数很高,我想主要还是架构问题,架构好了开发人员可以把更多时间放在业务上,而不是关注一些相对底层的繁琐的问题。我原来的想法是采用CMP,JDBC,JBuilder X,这样可以克服很多问题,但公司要用hibernate,这样的话JBuilder X的很多功能就用不上了,我觉得用hibernate也很好,但要把公司的代码生成器修改一下来适应这种架构。另外对JBoss我也有些疑问,假如我们在做一些深层次的开发遇到bug该怎么办呢,我一直用WebLogic,对JBoss没把握。

banq
2005-02-07 11:20
只有走过弯路,才知道架构选择的重要性。架构是方向的选择。

你们以前公司的代码生成器,可能是一种不具备多层结构的框架,所以,虽然使用的是Java/J2EE,但是可能没有利用先进的设计思想,这是Java/J2EE实践中最忌讳的。

你现在改用Hibernate这样的O/R mapping,将代码生成局限在J2EE的持久层,不会涉及生成Jsp等前台文件,算是走上了多层结构的轨道,但是,别乐观太早,你会碰上多层结构本身的麻烦,所以你要充分估计到这些问题和风险,允许我插一句,做一下广告:(jdonframeowrk就是为降低多层结构这些问题和风险提出的快速开发框架)


另外,你还要研究,你们原来的架构真正问题在哪里,换了Hibernate这样新的东东,会不会没有解决以前的问题,因为从的谈论中:
"数据存取文件里的函数太大,sql语句太长,再加上需求变更频繁且变化幅度大", 我感觉Hibernate可能不是完全适合你们,要注意现在O/R mapping技术没有完全成熟,如果成熟就会纳入J2EE规范里,所以选择O/R mapping技术时,要避免“爱人现象”,你的真正爱人也许并不符合你心目中的理想模型。
另外,使用Hiberbnate,要将系统分析和设计转向完全面向Model设计上来,在O/R mapping概念中,数据库只是持久层的实现,变成很渺小 不重要的地步,以往那种数据库万能的概念要得到清洗,建立一个项目首先不是规划好数据表,而是做好UML 等
模型设计。

你说:”新架构的目标就是为开发人员提供一个技术与业务的平台,但做起来是有相当难度的,首先公司对ejb技术,struts,hibernate,设计模式不太熟悉“。
这是正常现象,因为你们的重点是业务逻辑,是ERP,所以,你们没有时间精力专注于J2EE技术架构,我建议你寻找专业的咨询公司或现成的、有良好的设计的框架
作为你们的新架构基础。这也符合术业有专攻,市场细化的原则。很少有一家应用软件公司会“通吃” java领域所有技术。

如果你以前使用weblogic,可以一直使用它,除非有其它原因,JBoss也不会让人担心,JBoss 4.0通过J2EE 1.4认证,这个认证需要严格的测试和指标,因此,
我们需要改变以往著名商业公司就会出好产品的印象。而且我们的编程是基于J2EE标准包括EJB标准,如果我们的编程是完全按照标准行事,作为标准的另外一个
容器实施者JBoss当然不会有问题,这也是通过认证的意义。在J2EE/EJB这些环节上,国际上有多种力量平衡,独自分工,这里类似浙江的私营企业生产出的标准机械部件
照样出口畅销一样。

如果没有标准,这时你就要多考虑一些,多留一些心眼,类如struts、Hibernate、Spring等,当然也包括JdonFramework.这时需要的是:你能够理解这些开源的架构,对其有信心,出了问题你能动手自己修修补补,或能找到为你修补的人或单位。

xujun
2005-02-16 16:39
对于象我这样的小公司,本身的技术人员就不多,想实现技术转型或者是架构重新设计,感觉是自己一个人在拼命工作。遇到问题只能自己找资料解决,痛苦啊!

leexhwhy
2005-02-20 12:58
前几天还可以看到关于XXX框架的讨论,争论很激烈,现在全看不到了,希望BANG的心胸开阔一些,不要删不同的意见了。
这样很没有意思。

SportsBaby1980
2005-02-21 12:57
呵呵

可行

我已经完成了关键的部分,

可以作开发适用。

SportsBaby1980
2005-02-21 12:58
主要是适用
struts
hibernate
jdo

husthxd
2005-02-21 13:26
这个架构开发速度还比较快,但维护起来太麻烦了,增减字段改起来很麻烦,而且数据存取文件里的函数太大,sql语句太长,再加上需求变更频繁且变化幅度大,整个架构难以适应这种变化,业务逻辑也得不到重用。

-->

数据库增删改字段不管采用什么技术都比较的麻烦,伴随增删改的是需求的变化以及业务逻辑的修改.
需求变化实现业务逻辑的代码不更改是不可能的,看改得多还是改的少了.
可以参考:
http://blog.itpub.net/post/11/14219

wilson_qd
2005-03-02 16:25
我以前也是做ERP的,后来到一家使用多年j2ee架构的做b/s模式系统的公司。该公司曾经用过ejb架构、一套自己的mvc架构、struts架构。我现在把公司软件产品做成代码生产器方式,在架构上只使用简单的东西,而且当数据量很大时,数据库SQL优化已经很重要,许多地方要自己找到最优方式,不可能简单的使用别人的工具。公司已经在几个项目中使用,觉得这种方式很好。做项目时可以快速开发完成,后期维护费用也很低。现在使用j2ee架构做项目的公司多数都是专为某个项目做的,很少有像做ERP一样做成一个行业通用产品的,如果你现在要做成通用产品,我觉得像我们现在这样就比较好。不要去一味追寻j2ee架构,要做成自己的基于某行业的架构。

banq
2005-03-02 17:47
wilson_qd 非常棒:做成自己的基于某行业的架构,可否分享一下你的设计实现,也许正好可以解决楼主提出的问题。

wilson_qd
2005-03-03 16:00
哈哈,见笑了,这套架构的最终完成归功与公司整个开发团队,我只是提出了这一思想并做成了主要实现,还不是架构师。

banq
2005-03-04 10:08
过谦了,在不泄密的前提下,能否贴些稍微详细的资料让大家分享一下?谢谢。

JoannaYe
2005-03-08 20:21
我怀疑在没有真正懂得某一领域Business的情况下,是否可能作出通用的架构.我也怀疑目前在中国的软件开发领域是否有这方面的人才.

ouhua
2005-03-13 16:32
架构应该包括技术架构和业务架构,有业务分析人员和技术设计人员合作完成,两者都是有相当难度的,如果公司的实力有限,那就要专注于某个行业做架构了,我们现在也是专注于一个行业做ERP。
对于代码生成器,我觉得应该尽量少使用。我们项目中使用代码生成器生成一些对数据库的增删改查程序,javabean,jsp,从表面上看的确加快了开发效率,避免人工写一些重复代码,但我觉得之所以会出现重复代码是因为设计上的问题,如果能很好采用面向对象技术,组件技术,设计模式,那么重复代码基本上不会出现。现在的架构是过程化的,业务逻辑过度分散,存在很多问题。

猜你喜欢
2Go 1 2 下一页