眼前出现这么一坨坨的文件夹，相信很多人已经看不下去了。是的，首先就是要把它给做掉。
按照这个项目文件夹的命名意图，大概可以划分如下：
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你就不管了吗？她不是你生的？
就是这个泼出去的水，你生的还要我来擦屁股。这里仅仅只是吐槽罢了。