说来惭愧，毕业四年，现在才开始着手框架的事情，着实脸红，之前都是拿来主义，这几年来跳过两次槽，从一个菜鸟小白到资深小白，新业务，新领域，新技术都有所接触，工作上能应付的来。从最开始读了一本《 JaveScrit Dom 编程艺术》，便觉 js在手，天下我有。等读完《锋利的Jquery》，还是 Jquery 更香一些。到后来的 Vue ，Element 等等，书读的越多，用的越多，越是觉得自己还止步于山脚。每每开发完一个模块，一个项目带来的不是成就感，而是不少遗憾。总觉得再给我一次重来的机会，我就会怎样怎样，如何如何，绝不会如此设计，总想着推到重来，最后却停在口头上，寄托在下一个项目。做开发越久，越觉得思想最重要，理清头绪，设计好思路比一开始就迫不及待去下手要好的多。实习那会拿到任务总想赶紧做完，立马下手。那时很多都未考虑周全，出过一些问题，算上后期填坑的时间，花费的总时间更多。时间真的要靠挤，不然他就悄悄溜走。忙不完的项目，还有考试，不然真没多的时间来写随笔和更新GitHub。趁着下一个项目还没开始，记录一下
为什么要有框架，MVC项目自带不是有model，view伪三层吗？ 其实框架说白了是分层，分层的目的是解耦，为了方便拓展。分层有 数据层，业务层，模型层，接口层， Web层 等等，并不是层越多越好，要根据实际业务考虑，不要纠结层数，分层只是手段。比如我就一个小小个几百上千的用户量，分个七八层让人看得眼花缭乱，真是没必要。数据库设计这一块，有ado.net 和 EF，其中EF 又有DbFirst、ModelFirst，CodeFirst ，根据不同的项目选择访问数据的方式，没有所谓的高端低端，第一实现功能，然后是稳定，高效。这里记录一下 EF ，关于EF 很多人都 看不起 DbFirst ，觉得 CodeFirst才是王道。实际并非如此。对于微小项目，包括服务，这里使用Dbfirst 就很是方便，又比如基于现有的数据库中某几个表的操作，并不是所有表。使用 DbFirst 会有一个疑问，edmx 文件到底算哪一层呢，分到 模型层吧，它又有 继承 DbContext 的类，new一下这个类就可以获取实体表数据，把它分到数据层吧，它又有表对应的实体类，真是纠结，上网百度一下，也没什么好的解决方式，有说新建两个edmx的，一个删除 实体，一个删除contenxt ，仔细想想，觉得很别扭。
我想的是，把它作为模型层，注释或者删除继承 DbContext 的类文件，然后再DLL数据访问层 中重写此类，当然也可以复制过去。这样一来，看起来顺眼多了。
对于CodeFist 我接触晚一些，在我们开发项目的时候，很多时候数据库已经存在，从0到1的项目并不是很多。一方面是狭隘的认为有了数据库，CodeFirst 就没有用武之地了，另外一方面觉得修改表结构需要通过指令来操作太麻烦，实则不然，自EntityFrameWork6.0以后，新建项-选择实体时会出现一个 来自CodeFist的项，这里就是方便在已经存在数据库的情况下，很方便的使用CodeFist，点击这个，下一步，下一步，选择所在的数据库，便会创建所选的实体
当然这些实体属于模型层，在数据访问层中 执行相关指令即可
1. Enable-Migrations 启用一个映射
2. Add-Migration InitialCreate -IgnoreChanges 添加一个映射，忽略数据库变化（不对数据库多更改）
3. Add-Migration xxxx 表结构有变化时执行下
4. Update-Database 更新数据库
基于现有数据库的情况，若不做表结构改动，依次执行1,2,4。 当表结构有改动的时候（数据库迁移），依次执行 1,2,3,4 . 关于CodeFirst 网上的资源要比 DbFist多得多，百度一下，内容很丰富，不知为何念书的时候，任课老师只教了DbFist. 这里记录一下数据库的操作，这里算是先行篇，接下来会把项目完整了放上去，并附上源码，吃过源码不全的坑，很是浪费时间和精力，而且还会增加更多的疑问。