远程调用项目规范总结大致如下，架构不一定与这个架构一样，但基本上是差不多的，有的项目使用maven管理只需要建立两个项目。

远程调用分布式的核心思想：面向接口编程，代码切割 ，负载均衡，服务器缓存。

以下的规范都是为了方便实现其核心精神。

数据实体遵循ORM映射机制。

实体属性命名格式mouldName;不带下划线，可以使用工具generator eclipse插件自动化生成实体类和映射Mapper.xml文件


远程调用分层格式


客户端工程

前端：js  ,  p_w_picpath  , CSS ，Html 分开，采用连接形式。插件独立。

  Action层：  命名以--Action后缀结尾。

其他工具层：

接口工程：

远程调用接口：以--Remote后缀结尾。

数据库实体层：

 其他数据实体：添加一些数据库不包含的字段，可以继承数据库实体。

 其他工具层：

 返回数据层：封装了返回数据，包括返回码和其它信息。

 

 

远程服务工程：

远程接口实现层：实现接口工程中的接口。并调用业务逻辑层。以--RemoteImpl后缀                                结尾。

业务逻辑层：分为接口层，和实现层，以--Service和--ServiceImpl后缀结尾。处理                             业务逻辑和事务。

数据库层：分为接口层，和实现层，以--Dao后缀结尾

其他工具层：

数据库映射文件命名空间开启：能防止命名冲突

SqlMapConfig.xml中setting下的useStatementNamespaces="true"

各映射文件中  <sqlMap namespace="user" >

调用this.client_r.queryForList("getUserById");

this关键字的使用，能提高代码的可读性。

异常的try---catch  和   throw  的差别。

异常在哪里出现的就在哪里try---catch捕获，能更好的进行异常精确定位。也为了更好的实现         后期日志处理。

throw会将异常往上抛，抛给上一层处理。       

          

命名实体层一般用 英文中的名词。服务层、控制转发层和数据层 一般使用带动作的词，用英         文单词拼接，不能使用简写，命名要达到能表达功能，可以做到零注释编写。

服务层编写一般一张表对应一个实体对应一个数据库访问层，对应一个业务逻辑层。业务逻辑         需要操作多表的，

需要看最终返回的结果是一那个实体为主，就归类在哪里，这里是为了实现代码的相关性。希         望去看一下《重构-改善既有代码》这本书，把上面那个案例操作一下，很有帮助的。

          

          

一个类中代码块顺序格式：

      private static final

      private HomPushRemote

      private int userId;

      get,set方法

                 功能方法

调试打印，避免sysout. 采用日志打印,可以区别多种类型的信息打印,也为了方便后期日志处         理。

        private static Logger log = Logger.getLogger(HomProductAction.class);

        log.debug("");

    

        远程服务层的接口命名不能带有客户端层的业务含义。做到接口的统一，为了实现接口的简           单，和共用性。

           

        代码编写从业务需求开始，到Action层，思考需要哪些接口，去接口工程中查看是否已经有           了该功能的接口，没有再创建。

        一层一层的自顶向下驱动开发，减少代码的冗余。一般增删改查这个四个功能，插件可以自           动生成的。

                      

       action层根据需求来区分建包建类，同一模块的页面放在同一个包中，一层一层的。

       ibatis映射文件结构

    文件命名空间配置

    sqlMap

    共用sql语句块

    功能语句块