架构问题

你们以前的架构是什么？能否一说？

以前的架构的主要问题就是在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没把握。

只有走过弯路，才知道架构选择的重要性。架构是方向的选择。

你们以前公司的代码生成器，可能是一种不具备多层结构的框架，所以，虽然使用的是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.这时需要的是：你能够理解这些开源的架构，对其有信心，出了问题你能动手自己修修补补，或能找到为你修补的人或单位。

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

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

呵呵

可行

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

可以作开发适用。

主要是适用
struts
hibernate
jdo

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

-->

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

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

wilson_qd 非常棒：做成自己的基于某行业的架构，可否分享一下你的设计实现，也许正好可以解决楼主提出的问题。

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

过谦了，在不泄密的前提下，能否贴些稍微详细的资料让大家分享一下？谢谢。

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

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