G.系列导航
分析目前项目结构
眼前出现这么一坨坨的文件夹，相信很多人已经看不下去了。是的，首先就是要把它给做掉。
按照这个项目文件夹的命名意图，大概可以划分如下：
1.Business：业务代码
2.Data：数据访问
3.Helpers：辅助类（通用类库之类的）
4.Models：各种模型（包括视图模型）
5.theme：皮肤，还有一些content、scripts之类的应该是要删除或整理到theme中。
6.Controller、Views、DB：这些就先不动他了。
按文件夹名的意图重新整理项目结构
首先整理出4个解决方案文件夹（注：解决方案文件夹是个虚拟的结构，并非真实的物理文件夹，虽然源码存放位置也缺失按照目前分层做的，但这个概念要分开），分别是 Business、Model、Data、Infrastructure，将业务、模型、数据、基础设施给分拆出来。
其中Business、Model两个文件夹主要与业务相关，这两个文件夹会根据功能模块创建对应的项目，比如 DeployManage、UserManage等。像部署下的一些小的概念，如部署服务器、部署服务器组、部署项目等这些只需要在对应项目下创建1级文件夹区分开即可。
而Data下拆分为2个，主要考虑到 Wrapper 是给Business用的，主要用来访问数据库，而Entities则是用于存放数据表对应的实体类。
最后的Infrastructure则把一些公共的类放到了这里。
可能有人不禁要问一下，就这么简单？这就是最终项目结构了吗？
当然不是，重构即是一个动作，也是一个过程。后面会根据项目发展不断的进行重构。
迁移过程中遇到的问题与解决
1.李鬼李逵傻傻分不清楚
首先遇到的问题则是它，AuthenticationDescription，按照已有的命名空间引用，正常推论是只要引用 Microsoft.Owin.Security.dll 就可以了。但事实证明不行。
为了知道到底是什么原因，我又把这个类放回原来的位置，F12跟踪进去一看，嘿，原来是个李鬼装李逵。
最终通过添加了Microsoft.Owin.dll 解决，这个类其实跟Microsoft.Owin.Security.dll没关系的。真真是被戏耍了一番。
2.雷锋，你做了好事倒是留个名啊
大家可能比较喜欢使用vs自带的这个小灯泡，是的它很方便，但它不是万能的。如果你按照这里的选项来做你有2个选择，要么新建一个类自己实现，要么引用 System.Runtime.Remoting.Context
虽然通过上面的办法我们也能找到最终是谁做的好事，但这个时候经验出现了，我一眼就看出来这是EF帮忙扩展了的（毕竟踩的坑多）。它做了好事儿，但它还没留下自己的名字，只告诉我它是个无名氏。当初第一次踩这个坑也是通过第一个方法解决的，性质跟是一样的，但这里想告诉大家，积累也很重要。
当处理到Business的时候，发现它终于可以给一个正确的提示了，这就好像A是B的老婆，B是C的同事，C认识B自然问B就知道A是谁了。
3.你女儿嫁人了她还是你女儿啊
把引用关系都改好了，过程中修改名字也都使用了大家喜欢的小灯泡同时更改所有的引用，为什么还会出现这个问题？难道View你就不管了吗？她不是你生的？
就是这个泼出去的水，你生的还要我来擦屁股。这里仅仅只是吐槽罢了。
看到了这个页面我长舒了一口气，终于是不报错了。
再来看下 G.Client.UI.Admin 好像是顺眼多了。
但这就改完了吗？这只是个开始而已，后面的路还长呢。
4.青春痘长在别人脸上你最不担心？
好好的一个业务层代码，引用了EF，着实是不爽。不仅如此，Model里也引用了System.Web来获取UserID。
作为一个有道德的人，别人脸上长了青春痘，你应该拿个扬声器对着他喊：喂，你脸上有青春痘，好大一颗，好难看！
nonono，作为一个有文化的人，我当然会解决你的痛处。而不是现在，后面一定会做的。其实很简单，只需要在Wrapper里封装好EF的操作，让Business不会直接引用到EF相关的功能即可。（这个是.net的机制不深究了）
同样的，System.Web的也通过Infrastructure里提供就好了。从此再也不担心青春痘乱长了。
代码方面的调整
作为一个懒人，第一个要解决的肯定是解放双手。
后面对数据库操作的还有好多地方，到处都要这样赋值真的是心疼自己细白嫩长的五指。
已经有很多人想到了AutoMapper吧？当然也有人喜欢EmitMapper等等。各有所长，萝卜白菜自己挑一个啃了吧。用法我就不多说了，看个最终代码。当然我用的是自己又封装一次的AutoMapper。
即便AutoMapper已经很灵活了，但每个人的习惯不同，总有你觉得不爽的地方，那就自己动手吧。
啧啧啧，瞬间又顺眼了好多，整个人都好了。
PS：这次引用的Mapper是我们自己写的，Framework.Mapping和Framework.Caching。暂时还没有开源，后面会放出来，其实也没加壳混淆，你有兴趣肯定难不住你的。
下一篇预告：【G】开源的分布式部署解决方案（三） - 部署项目管理（以Jenkins为例，准备好部署文件包）
G.开源分布式部署 QQ群：601476986 （本群会实时更新进度，相比来说肯定比博客频繁得多）
Git地址：http://git.oschina.net/doddgu/G （希望大家可以顺手点个star，感谢各位的支持）