JavaWeb开发技术

最新推荐文章于 2022-02-23 14:56:30 发布

cuijiao8029

最新推荐文章于 2022-02-23 14:56:30 发布

阅读量112

点赞数

今天早上开会的时候，我这样的列举了一下——按照目前比较流行的“分层”概念划分。

Web UI MVC ： Jakarta Struts ， Spring MVC ， Jakarta Velocity

1. Jakarta Struts：优秀的Web UI映射、验证架构，有点毋须多言，比较完美的剥离了界面与业务逻辑

2. Spring MVC：我看了Spring Tutorial中介绍的Spring MVC，就是之前提到的Web UI层架构，在做了几个例子和Struts比较之后，认为这是一个发展中的东西，目前比较Ugly，相较于Struts的从form-bean到action，再到validate等等的优秀设计，Spring MVC完全是未长大的孩子。

3. Jakarta Velocity：为apache jakarta下面的一个Web模板语言项目，有别于Struts和Spring MVC，但由于这个项目是关注于通过模板生成页面，也属于Web开发中的UI范畴，故列在这里，个人意见可以和Web UI架构复合使用，简化页面开发的流程。

O/R Mapping Tools(Or Persistence Framework) ：

1. Spring：比较完美的实现了依赖注入和控制反转，完全轻量级的持久层架构，优点是效率较高，且应用此架构的项目，开发周期较其它持久层要短，有利于XP和TDD开发过程。

2. Hibernate：应该是目前应用最广的O/R mapping工具，持久层架构，提供了事务控制，版本控制、对象缓存等等技术，可以较好的解决EJB映射关联及继承的缺点。并且提供了hbm2java,hbm2ddl等工具，通过Class.hbm.xml自动生成数据库表的脚本，并且生成基本的Java代码。值得一提的是，应用Xdoclet工具，可以通过在代码的注释中加hibernate tag的方法来生成hbm.xml文件，并且生成对应于不同数据库的SQL Schema。疑点在运行效率，我前几天在JBoss上做了几个示例，感觉效率不高，目前还在研究中。

3. Ibatis：经常在国外的一些论坛上看到有人拿这个出来和Spring、Hibernate做比较，没见过

4. toque：猫扑在应用的持久层工具，浏览过一次，没有太深印象

有一点值得一提的是，Hibernate、Spring以及Ibatis等持久层框架，关注的是持久化服务中的不同方面。这在我上面的简述中大概可以找到一些线索，所以在我看来，网上的一些关于这几类持久层框架的争论（甚至有的到了谩骂的程度，真是什么人都有）完全没有必要，找到合适的工具，才是王道。

App Server 、中间件服务器：

1. Apache：最流行的Http服务器，目前几乎大部分的Http服务器、php，perl服务器，J2EE App Server，都是以Apache为内核。

2. Apache Tomcat：内嵌Apache的Java Web服务器，提供Servlet容器，无EJB容器

3. JBoss：开源软件靠咨询、服务盈利的范例，提供build-in tomcat版本和independ版本，提供EJB容器，最新版本JBoss 4.0支持EJB3.0（似乎，我不太确定，大家感兴趣可以了解一下）

4. Resin：应用程序服务器，Servlet容器免费，EJB容器收费

报表工具

1. JasperReport: 在之前那个公司时搞过这个东西，现在基本忘光了，提供比较不错的报表绘制功能，并且可以实现导出到excel

2. 其它的Java报表工具：google一下Java 报表工具，估计能找出n多来，对于一个企业，报表自然重要无比，可是我似乎没有听说过我们公司有专门的报表开发团队，不过中行有的是钱，买来一套也未尝不可。

其它开源技术：

1. dom4j：document object model的java版本，专注与文档管理

2. sax：simple api for xml 专注与xml树的结构事件，需要用户自身维护xml树结构，处理速度较快

3. Apache Xerces：Apache的XML parser

4. Apache Xlan：Apache XML Stylesheet Transfom process tools，一句话就是在XML和HTML，XML和XML etc之间进行转换的处理工具

5. Apache Log4j：日志工具，在外汇收支申报系统中已有应用

6. AOP-J：实现按方面（切片）编程，自认为比较好的提供了解决类似权限问题的方法。在实践了范例之后，我认为AOP-J是一个不好的工具。因为它的实现是依据AOP模板语言强编译代码，在代码中插入处理方面的片断来解决面向切片的编程问题，这样生成的代码第一是可维护性差，第二是无法实现反向生成，对于后期代码维护，错误提取增强了复杂性。并且我感觉反向生成工具不晓得能啥时候搞出来，更不晓得谁在搞这个没有

操作系统我就不列了，反正就linux一个，我也没水平做一个概括。至于数据库，我觉得Oracle蛮好，MySql如果公司出于成本控制等因素考虑，选了他咱也没意见，做呗。

下面是我关于这次总工室开展Web开源软件调查的一点看法。早上和总工室的同事沟通（大部分时间都是在听），我理解总工室这次“Web开源运动”的目的如下：

1. 通过确定确定架构性软件（自己开发或者引用开源），规范产品设计的架构，推动Web项目的分层，实现各层次间的松散耦合，增强软件产品的强壮性、可延展性以及可维护性。（可维护性是我自己推导出来的，因为我的同意软件可维护性最重要这种说法，而且坚持写程序是为了给后来人看的，而不仅仅是为了能运行这个简单的目的，所以从前面的这些说法，我推导出的结论就是可维护性。好的架构、好的开发风格、清晰的程序代码、完备的注释及logging语句，在我看来都是为了可维护性。因为一个软件，一个项目，我们用四个月五个月或者半年的时间来开发，却可能要用三年五年甚至十年八年的时间来维护，软件危机就是起源于系统由于修改而导致不可维护）

2. 通过对开源软件的管理规避风险。简单说就是别让我们自己都不知道所用工具的漏洞所在，别让人家告我们。

我认为这次总工室的想法是好的，但是有一些问题需要进一步分离：

1. 一个架构性的东西是否适用于所有业务需求：持久层框架是典型的例子，Spring和Hibernate关注的是持久化的不同方面，他们提供的是同一类型的服务，但是可能适用的领域不同。dom4j和sax同样也是如此，我们不能视图用一个模式去涵盖所有问题。这样做的结果基本上会在某些情况下导致性能、效率的丧失，并且，也会影响项目开发的进程。Spring和Hibernate的差异，便在与此。我们能忍受这点吗？

2. 中间层，服务性框架的使用能使程序趋向于分层，但是这并不能提升我们的设计，好的产品、项目，它的业务逻辑是决定其可维护性的基础。一个产品的设计中，必须考虑有良好的封装性，遵守“Open-Close”，组合优于继承等等原则，以实现良好的可延展性和可维护性，这些是业务相关架构无关的，必须以我们技术人员自身水平的提高为前提。

3. 这次“Web开源运动”过去之后，我们会得到一个什么样的结果？做为一个开发人员，这个问题是我最关心的。是总工室确定一套可选的、涵盖了绝大多数方面的备选方案，在我们开发时依据需要进行使用？还是总工室最后只是建立了一个流程，我们以后在开发时可以使用开源的软件，立项开发前需要提交总工室审批？这两个方案对开发效率的影响显然是截然不同的。

4. 怎样保持我们公司的技术先进性？或许我提这个问题有些越俎代庖，但是，我觉得这个问题有提出的必要。首先这个技术先进性我们先不把它理解为我们要去了解最新的技术，我们把它理解为对一个优秀的、经过完备测试的并且是多方实践过的软件的理解与运用能力。那么从对技术先进性的这种理解出发，今后有同样优秀的开源软件出现，我们能否去应用他们？怎么去应用他们？我们对相关的产品进行了探索和研究之后，要在多长的周期内能将其应用在我们的研发中？我相信这是保持我们所认为的“技术先进性”所必须要考虑的。

拉杂了这么多，向坚持看完的兄弟鞠躬。再抒情一下：其实Java系统本身就是一个外延的，开放的平台，从EJB3.0将Hibernate和Spring纳入参考，从EJB3.0出于使用的方便性做出的修改（例如Session Bean远程调用的使用变得极其简单），从网上如此兴旺的Java开源项目（大家可以看看www.jcp.org下面那个长长的列表），不难看出Java发展的基础在于开源，而软件业的趋势也将是服务重于产品。我坚信这点。最后想起今天谢品说了一句话，触动颇多，就引用来做为文章的结尾：我们的思想能不能更open一些？