MVC 简单框架起步-数据（一）
说来惭愧，毕业四年，现在才开始着手框架的事情，着实脸红，之前都是拿来主义，这几年来跳过两次槽，从一个菜鸟小白到资深小白，新业务，新领域，新技术都有所接触，工作上能应付的来。从最开始读了一本《 JaveScrit Dom 编程艺术》，便觉 js在手，前端我有。等读完《锋利的Jquery》，还是 Jquery 更香一些。到后来的 Vue ，Element 等等，书读的越多，用的越多，越是觉得自己还止步于山脚。每每开发完一个模块，一个项目带来的不是成就感，而是不少遗憾。总觉得再给我一次重来的机会，我就会怎样怎样，如何如何，绝不会如此设计，总想着推到重来，最后却停在口头上，寄托在下一个项目。做开发越久，越觉得思想最重要，理清头绪，设计好思路比一开始就迫不及待去下手要好的多。实习那会拿到任务总想赶紧做完，立马下手。那时很多都未考虑周全，出过一些问题，算上后期填坑的时间，花费的总时间更多。时间真的要靠挤，不然他就悄悄溜走。忙不完的项目，还有考试，不然真没多的时间来写随笔和更新GitHub。趁着下一个项目还没开始，记录一下
为什么要有框架，MVC项目自带不是有model，view伪三层吗？ 其实框架说白了是分层，分层的目的是解耦，为了方便拓展。分层有 数据层，业务层，模型层，接口层， Web层 等等，并不是层越多越好，要根据实际业务考虑，不要纠结层数，分层只是手段。比如我就一个小小个几百上千的用户量，分个七八层让人看得眼花缭乱，真是没必要，还有一个就是设计模式，设计模式不算是框架，只是一套能较好的解决某类业务的思想或者说是一中方法，诸如工厂类，单例等等。当然了项目第一步，很多都是从数据库开始，有原生ado.net 和 ORM 映射，ORM中EF占据主流，其中EF 又有DbFirst、ModelFirst，CodeFirst ，EF体量较大，小体量的还有Dapper之类的，也挺好用的，根据不同的项目选择访问数据的方式，没有所谓的高端低端，第一实现功能，然后是稳定，高效。这里记录一下 EF ，关于EF 很多人都 看不起 DbFirst ，觉得 CodeFirst才是王道。实际并非如此。对于开发周期短的小项目，这里使用Dbfirst 就很是方便，尤其如服务， 只基于现有的数据库中某几个表进行操作，并非所有表。当然，在使用 DbFirst 时候会有一个疑问，edmx 文件到底算哪一层呢，分到 模型层吧，它又有 继承 DbContext 的类，new一下这个类就可以获取实体表数据，把它分到数据层吧，它又有表对应的实体类，真是纠结，上网百度一下，也没什么好的解决方式，有说新建两个edmx的，一个删除 实体，一个删除contenxt ，仔细想想，觉得很别扭。我想的是，只把它作为模型层，然后注释或者删除继承 DbContext 的类文件，然后在其DLL数据访问层 中重写此类，当然也可以复制过去。这样一来，看起来顺眼多了。
对于CodeFist 我接触晚一些，在我们开发项目的时候，很多时候数据库已经存在，从0到1的项目并不是很多。一方面是狭隘的认为有了数据库，CodeFirst 就没有用武之地了，另外一方面觉得修改表结构需要通过指令来操作太麻烦，也不安全，实则不然，自EntityFrameWork6.0以后，新建项-选择实体时会出现一个 来自CodeFist的项，这里就是方便在已经存在数据库的情况下，很方便的使用CodeFist，点击这个，下一步，下一步，选择所在的数据库，便会创建所选的实体
当然这些实体属于模型层，在数据访问层中（安装 EntityFramework）， 执行相关Nuget 指令即可，主要指令如下
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. 这里记录一下数据库的操作，
既然用到了EF，自然是免不了执行效率的考量，当需要对 EF 进行监听其生成的SQL时，操作如下
1.下载 MiniProfiler.EF6 包，然后选择对应的版本
2. 在全局文件中，加入执行指令
protected void Application_Start() { LogHelper.WriteInfo(" 开始.."); AreaRegistration.RegisterAllAreas(); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes); BundleConfig.RegisterBundles(BundleTable.Bundles); //注册EF 追踪 MiniProfilerEF6.Initialize(); } protected void Application_BeginRequest() { MiniProfiler.Start(); } protected void Application_EndRequest() { MiniProfiler.Stop(); }
3. 在 Web.Config 中加入对应配置
<system.webServer>
<handlers>
<add name="MiniProfiler" path="mini-profiler-resources/*" verb="*" type="System.Web.Routing.UrlRoutingModule" resourceType="Unspecified" preCondition="integratedMode" />
</handlers>
</system.webServer>
4. 在所需要监控的界面 中加入配置，当然可以放在母版页，这样处理更方便点
@using StackExchange.Profiling;
@MiniProfiler.RenderIncludes()
如此，运行到界面上，便可以查看所生成的SQL 语句，以及执行时间，之前以为 SQL 自带的那个 Profiler 监听是万能的，后来发现只能监听原生的 ADO.net 语句，对EF 操作望尘莫及.
接下来，尽量完整的记录下框架的一点点皮毛
