Liferay portal 相关总结（四）

六、强大的service-builder

上面我们留了一个悬念，那就是数据库中为什么会无缘无故多了这些表，我们没有写任何的T-SQL 语句，那就是portal 自己内建的什么机制帮我们完成了这个工作？！

 

事实证明我们的猜测是正确的，就是portal的内建service-builder机制，想要揭开这个机制的面纱就要从应用程序连接数据库的历史开始说起。(作者这个脑残又开始罗嗦了。。。)请允许我唠叨几句，也许有这几句唠叨能让service-builder的优点更加清晰的展现在各位看官眼前。

我们就从JDBC开始，JDBC提供给了程序访问数据库的一个接口，使用jdbc，程序可以轻松的访问特定的数据库。

JDBC：

优点：有清晰的接口，能够比较轻松的访问数据库中数据。

缺点：带来了SQL Injection(就是传说中的SQL注入)风险。

         然后登场的是EJB，主要用于早期企业级的开发中，EJB是Enterprise Java Bean的简称。

    EJB：

        优点：提供统一的容器来管理连接池，动态的插入参数等等功能。

        缺点：EJB很难进行编写，而且EJB就是一只吃内存和处理器资源的老虎。

        接下来上场的这货大家可能就比较熟悉了，就是开源的轻量级的ORM工具Hibernate。相较于EJB，其更加轻量级，提供很好的接口，将数据库表中的字段映射到类中属性。

    Hibernate：

         优点：服用性很强，比较灵活。

         缺点：配置过程相对比较复杂。

    最后登场的这个，就是今天要介绍的service-builder，这个玩意儿我也使接触portal以后才知道的，其也使依赖于portal这个平台，这个可能就是它首当其冲的缺点。

    首先来看Liferay in Action中是怎么介绍service-builder的：

    What if you could define a database table in an XML file and, from that definition, generate all the Hibernate configurations, all the Spring configurations, finder methods, the model layer, the SQL to create the table on all leading databases, and the entire Data Access Object (DAO) layer in one fell swoop? That’s what Service Builder gives you.

看懂得人可能就已经开始欢呼了，我擦，一个xml搞定数据库，表之间依赖，Hibernate, Spring配置信息，SQL语句，最重要的是还有整个DAO层。

    接下来看一下这个service-builder在整个程序结构中的位置：

图片来自于《lifray in Action》

    这个service-builder的核心就是一个xml文件，这个xml文件就是在如图中的文件目录结构中：

这个service.xml文件可以使用我们的IDE环境进行创建，也可以自己手动进行创建，主要介绍一下利用这个IDE创建service-builder，IDE中集成了利用ant使用service.xml文件创建DB层(主要是sql文件的生成)，Hibernate层(主要是Hibernate配置文件的生成)以及Spring层(Spring配置文件的生成已经所有的bean对象的托管等)……过程简要的回顾一下：主要是选择java包的路径等信息，然后自动创建一个service.xml文件在工程的WEB-INF下，使用IDE的话，这个service.xml的信息也很好配置。

    根据这个系统自动生成的service.xml文件进行一下讲解：

/////file:/docroot/WEB-INF/service.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE service-builder PUBLIC "-//Liferay//DTD Service Builder 6.0.0//EN" "http://www.liferay.com/dtd/liferay-service-builder_6_0_0.dtd">①

<service-builder package-path="net.akx"> ②

    <author>AKX</author>

    <namespace>akx</namespace> ③

    <entity name="Foo" local-service="true" remote-service="true">

       <!-- PK fields -->

       <column name="fooId" type="long" primary="true" />

       <!-- Audit fields -->

       <column name="companyId" type="long" />

       <column name="userId" type="long" />

       <column name="userName" type="String" />

       <column name="createDate" type="Date" />

       <column name="modifiedDate" type="Date" />

       <!-- Other fields -->

       <column name="field1" type="String" />

       <column name="field2" type="boolean" />

       <column name="field3" type="int" />

       <column name="field4" type="Date" />

       <column name="field5" type="String" />

        <!-- Order -->

       <order by="asc">

           <order-column name="field1" />

       </order>④

        <!-- Finder methods -->

        <finder name="Field2" return-type="Collection">

           <finder-column name="field2" />

       </finder>⑤

    </entity>

</service-builder>

结合以上的service.xml文件进行一下说明：

① xml文件的定义头。

② 定义java源文件包路径

③ 绑定javadoc，确定命名空间，命名空间影响数据库表名称。见下文

④ 使用entity标签定义数据库表，其中嵌入column标签定义数据库中字段，定义索引字段及顺序。

⑤ 定义finder字段及返回值。

 

① 没什么可说的，是xml文件的定义头部。② 定义java源文件包路径，决定生成的java源文件的包路径。③ 绑定javadoc，是java注释的一种方法，大家都比较熟悉我就不多说了，这里通过author标签可以在javadoc中自动生成@author信息，一般用于进行版本的控制，命名空间这个主要影响表的名称，比如我的命名空间是akx而下面的entity标签的名字属性是Foo，则数据库中由Foo生成表的对应表名应该是akx_Foo。④ 使用entity声明数据库中的表，使用column进行表中字段的声明，可以指定字段名称，字段类型和是否是主键等。⑤ 定义finder字段及返回值，指定在DAO层方法，用于查找相应的符合条件的对象。

然后使用IDE中自带的ant脚本对service-builder注入项目进行配置，以上的过程是在这个service.xml文件配置成功后，使用IDE中自带的方法就能生成一堆东西。

我们来看一下能够生成的东西，说一句比较俗的话：真TMD多。。。