怎么说这个项目 项目架构 网络层中的协议封装

怎么说这个项目 项目架构 网络层中的协议封装：

说道这个项目我先说说在设计这个应用的时候怎么去处理购彩的流程的，首先是我们这个应用会自动的从服务器获取到当前销售期的信息，然后是用户选择彩种，用户按照彩种的玩法规则选定号码，号码选号后判断用户的登陆情况，获取到用户账户的信息，然后核实用户账户余额是否满足投注的需求，满足要求的话，就下投注订单到服务器中，等待服务器的回复。手机端接收服务器端的提示信息，如果成功的话，就扣除用户账户对应的余额。

把一个字符串的值变成一个MD5值，导入jar包common-codec.jar，调用里边的DigestUtils.md5Hex(“要变成md5值的字符串”)。

说说应用架构，首先是网络通信，手机客户端要有一个接口文档，协议封装的载体是xml，之后会使用HttpClient实现与服务器端的通信。

然后是业务操作，拿到xml后还要对其进行解析，业务层要进行公共信息的操作，比如购彩流程中获取当前销售的信息。然后是用户信息的处理，还要进行业务层调用，目的是降低耦合，因为整个项目是几个人一起做的，所以需要降低层与层之间的耦合度，解耦的操作常见的是模块与模块之间的，画图，现在每个模块都需要经过视图层、业务层和网络层，如果降低了层与层之间的耦合度，就会把项目分成很多低耦合的小块，互相之间不影响，这样在分工的时候，就可以让做界面的专门做界面，做业务好的专门做业务，做网络的专门做网络，这其实就是MVC的思想。

最后就是界面的展示，做的就是统一界面的管理。

画图。

三大块，网络层，业务层，界面。每一块所做的工作，网络层：第一个就是进行网络的封装，第二个就是要通过HttpClient编写通信工具，与服务器端进行通信。在业务层要处理三个部分：一是公共信息处理，二是用户业务处理，三是降低层与层之间的耦合度。最后是视图层，要做的是统一界面的管理。

具体操作看业务层的处理。

考虑到实际开发初期，只会有一个需求文档，而且与最终达到的效果不一样，需求文档只是功能上的描述。我们拿到文档，找到功能点，美工提供一些效果图给pm\leader看，选出来俩到三套图，最终决定权在公司老大手里，一般这个周期一段时间，作为开发人员不能等着，所以要从我们能先搞定的“数据”入手——先解决数据传输和处理问题，然后再处理界面。

因此要先进行网络层的处理（因为网络层与服务器打交道，也就是和数据打交道），再进行业务层处理，最后进行视图层的处理。

说说网络层，第一步要做的是对协议进行分析，如果按照通常的解析xml文件的方法，序列化，然后每一步都是START_DOCUMENT,END_DOCUMENT, START_TAG, END_TAG, TEXT的话，代码就会写的非常非常多，就算写下来来，还会出现一些问题，要知道，我们这个项目是团队开发的，比如4个人吧，处理100个请求的话，如果不想写前面说的那么代码，就要对解析xml文件的代码进行简化，抽取成方法，这时候就又有问题了，4个人抽取，可能抽取出4个版本的代码，这时候，考虑到有人离职的风险，我们要是新招聘一个人来继续做，就要重新按照之前那个人抽取的方式再去熟悉这个代码，这就很浪费时间了，还影响到项目开发的进度。这只是一个问题，还要考虑如果这样做，我们这里的4个人都要去学习协议，这又要耗费一段时间，而且还要开一些项目会议去了解每个人对协议的学习情况，而如果协议有所改变，我们这4个人又都得停下来修改代码，这又是一个问题。要想解决这个问题，方法就是把抽取的方法统一成一个版本，也就是进行协议封装，抽取公共部分，协议封装的思路，用一句话来讲就是自己管自己，比如说一个叶子，把这个叶子的语句抽取成一个方法，只要是叶子，就把标签和值给这个封装出来的方法，然后把叶子封装到一个类中去，其他的一样向上抽取出一个方法，封装到一个类中。

封装时遇到的问题：这样封装只能处理这一个xml，解决的办法是将element通用化，只是将Element的公共部分，放到这个类里面。而不同之处需要项目组其他成员来处理。总的来说协议的封装要完成“四化”：也就是节点对象化。节点序列化。接口抽象化。协议通用化。