个人感觉这不是一个好方向，，，做个神马都要把密码带上，，，不过这样服务器设计确实简单很多，，，

从大局上看Mission是和整体的MVC框架协作的，那ServerListData来说，ServerList这一个逻辑可以单独出来，维护三个位置Data、Mission、View
具体到list data的获取都直接由Mission完成，其他模块之需要使用就OK，Mission自己有策略决定何时去获取，或者定时更新

//接收映射
const BYTE g_RecvByteMap[256]=
{
    0x51,0xA1,0x9E,0xB0,0x1E,0x83,0x1C,0x2D,0xE9,0x77,0x3D,0x13,0x93,0x10,0x45,0xFF,
    0x6D,0xC9,0x20,0x2F,0x1B,0x82,0x1A,0x7D,0xF5,0xCF,0x52,0xA8,0xD2,0xA4,0xB4,0x0B,
    0x31,0x97,0x57,0x19,0x34,0xDF,0x5B,0x41,0x58,0x49,0xAA,0x5F,0x0A,0xEF,0x88,0x01,
    0xDC,0x95,0xD4,0xAF,0x7B,0xE3,0x11,0x8E,0x9D,0x16,0x61,0x8C,0x84,0x3C,0x1F,0x5A,
    0x02,0x4F,0x39,0xFE,0x04,0x07,0x5C,0x8B,0xEE,0x66,0x33,0xC4,0xC8,0x59,0xB5,0x5D,
    0xC2,0x6C,0xF6,0x4D,0xFB,0xAE,0x4A,0x4B,0xF3,0x35,0x2C,0xCA,0x21,0x78,0x3B,0x03,
    0xFD,0x24,0xBD,0x25,0x37,0x29,0xAC,0x4E,0xF9,0x92,0x3A,0x32,0x4C,0xDA,0x06,0x5E,
    0x00,0x94,0x60,0xEC,0x17,0x98,0xD7,0x3E,0xCB,0x6A,0xA9,0xD9,0x9C,0xBB,0x08,0x8F,
    0x40,0xA0,0x6F,0x55,0x67,0x87,0x54,0x80,0xB2,0x36,0x47,0x22,0x44,0x63,0x05,0x6B,
    0xF0,0x0F,0xC7,0x90,0xC5,0x65,0xE2,0x64,0xFA,0xD5,0xDB,0x12,0x7A,0x0E,0xD8,0x7E,
    0x99,0xD1,0xE8,0xD6,0x86,0x27,0xBF,0xC1,0x6E,0xDE,0x9A,0x09,0x0D,0xAB,0xE1,0x91,
    0x56,0xCD,0xB3,0x76,0x0C,0xC3,0xD3,0x9F,0x42,0xB6,0x9B,0xE5,0x23,0xA7,0xAD,0x18,
    0xC6,0xF4,0xB8,0xBE,0x15,0x43,0x70,0xE0,0xE7,0xBC,0xF1,0xBA,0xA5,0xA6,0x53,0x75,
    0xE4,0xEB,0xE6,0x85,0x14,0x48,0xDD,0x38,0x2A,0xCC,0x7F,0xB1,0xC0,0x71,0x96,0xF8,
    0x3F,0x28,0xF2,0x69,0x74,0x68,0xB7,0xA3,0x50,0xD0,0x79,0x1D,0xFC,0xCE,0x8A,0x8D,
    0x2E,0x62,0x30,0xEA,0xED,0x2B,0x26,0xB9,0x81,0x7C,0x46,0x89,0x73,0xA2,0xF7,0x72
};
// MapSend
desData = g_SendByteMap[(BYTE)(srcData+m_cbSendRound)];
m_cbSendRound += 3;
// MapRecv
desData = g_RecvByteMap[cbData] - m_cbRecvRound;
m_cbRecvRound += 3;

映射加密原理分析：
约定srcData表示准备加密的数据desData表示加密后的数据，sendMap表示发送Map，recvMap表示接收Map；
就以上代码中恒有:
推导：
if desData == sendMap[srcData + offset]
then srcData == recvMap[desData] - offset
这个公式可以自己取一个[0, 255]之间的值，带到上面两个map中去算，，，
分析：
BYTE可能的值是0到255，正好是map的索引。
sendMap提供把实际值变成recvMap的索引的能力。
recvMap提供把recvMap索引还原成真实值的能力。
offset的引入是为了加强破解难度，唯一可能疑惑的问题是BYTE溢出，这个可以参考计算机组成原理前几章。
我们可以这样山寨：
class CSendMapper;
class CRecvMapper;
很显然sendMap是和CSendMapper类紧耦合的，recvMapper和CRecvMapper类紧耦合
所以：
class CSendMapper
  ;
class CRecvMapper
  static const BYTE[256] ms_recvMap;
接下来是offset，在网狐的代码中每次都有如下操作：m_cbSendRound += 3;
所以offset是和Mapper对象耦合的，同时也是上下文相关的，这样也倒置mapper是上下文相关的。
class CSendMapper
  static const BYTE[256] ms_sendMap;
  ;
class CRecvMapper
  static const BYTE[256] ms_recvMap;
  BYTE m_btOffset;

这样，只要是offset匹配的recv和send协作就能实现数据加解映射了，，，

最后的测试代码如下（MAP函数被实现的时候改了，返回值的做法写起来是方便了，但是优化的时候比较麻烦）：

nf6602::CSendMapper sendMapper;
_el::TBYTE btTem = 0;
sendMapper.SendMap(0, btTem);
if (0x70 != btTem)
{
    std::cout << "sendMapper.SendMap faild!" << std::endl;
}

nf6602::CRecvMapper recvMapper;
btTem = 0;
recvMapper.RecvMap(0, btTem);
if (0x51 != btTem)
{
    std::cout << "recvMapper.RecvMap faild!" << std::endl;
}

//if desData == sendMap[srcData]
//then srcData == recvMap[desData]
for (int i = 0; i < _EL_MAX_TBYTE*10; i++)
{
    _el::TBYTE btSrcData = i;
    _el::TBYTE btDesData = 0;
    sendMapper.SendMap(btSrcData, btTem);
    recvMapper.RecvMap(btTem, btDesData);
    if (btSrcData != btDesData)
    {
        std::cout << "if desData == sendMap[srcData] then srcData == recvMap[desData] faild!" << std::endl;
    }
    else
    {
        int j = 0 ;
    }
}

在来看那个help工具模版类
template <typename IModeluInterface> class CTempldateHelper
 //构造函数
 CTempldateHelper(REFGUID Guid, DWORD dwVersion);
 //构造函数
 CTempldateHelper(REFGUID Guid, DWORD dwVersion, LPCTSTR pszModuleDll, LPCSTR pszCreateProc);
两个构造函数，能看出点什么不，，，
// 这代表DLL的名，和DLL中创建组件的函数名，别告诉我你不知道动态加载dll
LPCTSTR pszModuleDll, LPCSTR pszCreateProc
// 这些稀烂班子就是隐藏了动态加载的过程而已
 //获取错误
 inline LPCTSTR GetErrorDescribe() const;
 //指针重载
 inline IModeluInterface * operator->() const;
 //获取接口
 inline IModeluInterface * GetInterface() const;

这样看起来很美，其实隐藏了太多东西，降低了代码的可读性。接口都看不到了，，，坑爹的，，，