基本是沿用的老方法，为兼容在XP系统上运行，选用的是基于.Net 4.0开发。由于.Net的版本限制，所以很多高级特性不能使用。简单封装了一些基本使用类，如序列化类（基于json.net）、api请求类（基于HttpWebRequest类封装）、日记记录（基于log4net）、缓存帮助类（基于mencached）、根据项目需要基本类型如Datetime、Int、String等类拓展了常用方法。客户端中由于考虑到一下情况，初版我做了如下规范：
所有需要调用接口的地方采取配置文件的形式，当时之所以会这样设计是应为考虑到，万一服务器控制器名或方法名发生变动可以在变动代码的前提下通过修改配置文件的形式实现快开发，这个想法出发点是好的，而且非常有利于代码的维护，但是没有考虑到代码不是自己一个人写，新开发的加入无疑增加培训成本。而且我自己开发过程发现需要在代码cs文件和配置文件中2个不同的地方来回切换很不方便浪费很多时间。
挖的第一个坑【采用大量配置文件导致开发效率低、培训成本大】
服务器
这边和老软件相比有了本质的变化，老软件的设计很无脑，实实在在的CS架构，客户端数据库直连的形式再加上存储过程。这里谈到存储过程，我谈谈自己开发定制项目自己的感受，存储过程最大的优势无疑是性能强悍，为什么这么说呢。主要是存储过程直接保存在数据库里面的，仅仅需要传输参数就可以而且sql本身会对其进行查询优化，就我的开发感受而言，我还没遇到哪个技术的处理速度能够高于存储过程的性能的。但是存储过程这玩意开发体验很差，首先需要熟悉sql语法，要熟悉sql基本函数，知道游标等等。所以说这是需要一个技术相对专业的人维护才行。但是实际情况是，面对小公司想找一个技术全面的人很难得，一般的开发在处理sql层面仅仅处在select、delete、update、add、where的层面，而将更多逻辑放在业务代码中处理。而且别人写的存储过程晦涩难懂，动不动上千行的存储过程实在让人看着绝望，嗯...绝望这个词用得好~~~哈哈哈。这么分析下来还是能得出结论了，存储过程这个技术是好的，但是弊大于利，以至于本次开发新系统直接摒弃该技术。但是不用存储过程带来的问题就是性能的大幅降低。为解决以上问题，结合自己积累的技术选择了基于别人一套的快熟开发框架来进行开发。核心技术点有持久层采用的EF 数据库优先，缓存采用的是Memcache、应用服务层采用webapi。就这样服务器基本就完成了，亮点技术及坑总结如下：
可能自己项目经验比较少，也有可能没做过业务有这么复杂的项目，让我从开发系统无非是CRUD（增删改查）的逻辑中脱离出来。为了快速开发（原因是人手不够、自己开发封装的水平又不高），在整个应用层面我采用了大量的T4模版结合EF框架实现的超乎想象的快速开发，只要数据库设计好，接下来只需要简单的配置，整个服务代码完全ok。但是这里需要注意的是需要一些约定，如主键的后缀一般采用表名+Id的命名规范等等。这种模式仅仅适用非常简单的业务代码开发，拿这个开发产品无疑是搬石头砸自己脚，随着项目的进行，业务不断复杂，我不断调整T4模版（写T4模版比写存储过程还恶心，这辈子再也不想写了）不断的加入各种各样的参数配置，使得生成的代码更能符合业务的需要。随着业务越来越深入，后来几个版本的迭代中我不断的把此技术剔除。
挖的第二个坑【采用大量T4模版，代码写代码的模式，然而并不知道，需求无时无刻不在变化】
由于干掉了存储过程，这里引入了分布式缓存的概念，在老系统中是没有这项技术的。为何要引入该技术呢，前面有提到软件速度慢。在没有缓存的系统中，数据是怎么呈现到用户眼前的呢？数据是读取硬盘中的文件加载到内存中最终呈现到用户的眼前，那么引入缓存的概念呢，直接读取内存，读到数据根据缓存键直接返数据否则取硬盘数据。由于读取内存中数据的速度远大于硬盘，所以说缓存的引入无疑是极大的提升系统的性能。原理虽然是这样，如何对数据进行缓存。哪些数据需要缓存？哪些数据不需要缓存？如何管理缓存键？等等一系列问题扑面而来。在系统开发过程中需要进行缓存的总结几点：1.不经常改动的数据；2.大量使用的数据。如果在系统中发现这样的数据，那么应该将他们进行缓存处理。比如：用户信息、公司信息、菜单信息、功能信息等等都是需要反复使用而不怎么修改的数据，我们应该进行缓存处理。试想：每次请求过来要进行身份校验、权限校验、数据校验等等都查询数据库的话，数据库压力可想而知。