【01】一起学ASP之《ASP.NET MVC企业级实战》

【1】我们平时写简单的使用数据库的代码，一般都是直接var db = new DBModel()之类的，讲究一些的会把这段代码写在using()里面，但是这不是很好的做法。主要原因是，如果我们涉及到多个DAL的话，那么每个DAL自己去创建一个DbContext，那么最终会导致混乱甚至脏读的出现，我们的目的就是尽量保证上下文只出现一个DbContext，目前我们可以通过HttpContext来实现，即把我们创建的DbContext放在它里面，因为我们一次请求就对应着一个HttpContext，我们在这个请求里进行一些操作，这个请求结束HttpContext就销毁了，放在它里面的DbContext也就销毁了，连我们手动销毁创建的DbContext这个步骤都省略了。所以，一般是在Commons里面新建一个工厂类，专门处理这一块创建的逻辑：

using System.Data.Entity;
using System.Web;
using Charpter01.EFModels;

namespace Charpter01.Common
{
    public class DBContextFactory
    {
        public static DbContext getDBContext()
        {
            DbContext dbContext = HttpContext.Current.Items["dbContext"] as DbContext;
            if(dbContext == null)
            {
                dbContext = new DBModel();
                HttpContext.Current.Items["dbContext"] = dbContext;
            }
            return dbContext;
        }

        public static void removeDBContext()
        {
            DbContext dbContext = HttpContext.Current.Items["dbContext"] as DbContext;
            if(dbContext != null)
            {
                HttpContext.Current.Items.Remove("dbContext");
            }
        }
        // 不需要手动销毁了，我们放在HttpContext里面，跟随着HttpContext的创建和毁灭
        //public static int saveChanges()
        //{
        //    return getDBContext().SaveChanges();
        //}
    }
}

【2】控制器向视图层传递数据的话，我们都知道使用ViewBag，我们还知道有一个ViewData，这里面ViewData是一个字典，使用方法就是ViewData["xxx"]，它的存取值可以看做是一个object，所以其实是要进行显示转换的；而ViewBag的使用方法更像是类和属性的使用，类似于ViewBag.xxx，它的存取值其实可以看做是一个dynamic，其实本质上ViewBag只是在ViewData外面做了一层层封装，这个封装之后，就不需要用户手动显示转换类型，程序会帮我们做类型的自动转换，所以理论上ViewBag因为多了一层封装性能上会稍微差于ViewData，但是这种差异几乎可以忽略不计。

【3】BundleConfig.cs文件的主要作用就是压缩静态文件，压缩的静态文件主要是css和js，但是要想它发挥作用，需要把项目的调试关闭。压缩的效果就是把页面引用的js文件全部打包成1个文件，请求次数也少了，总的文件大小也相对小了一点。css也同样处理，物以类聚。

<system.web>
    <compilation debug="false" targetFramework="4.5" />
    ...
  </system.web>

【4】如果使用MVC做web网站的话，估计大部分人都在使用Razor模板引擎，我们在指定的位置创建cshtml文件，它就会自动找到。我们可以看看它是怎么找的，要查看这个模板查找顺序的话，可以新建一个控制器比如PostController，然后就没有然后了，直接启动，然后在浏览器访问这个控制器http://localhost:7202/Post，后面不要跟Action什么的，就能看到它给我们的详细信息，这个相信信息里就有模板查找的顺序。

“/”应用程序中的服务器错误。
未找到视图“Index”或其母版视图，或没有视图引擎支持搜索的位置。搜索了以下位置: 
~/Views/Post/Index.aspx
~/Views/Post/Index.ascx
~/Views/Shared/Index.aspx
~/Views/Shared/Index.ascx
~/Views/Post/Index.cshtml
~/Views/Post/Index.vbhtml
~/Views/Shared/Index.cshtml
~/Views/Shared/Index.vbhtml

可以看到，这里面搜索了两个地方，一个是~/Views/Post/，一个是~/Views/Shared/，这个好理解，先去自己对应控制器的视图目录去找，找不到就去共享视图目录中找，但让人想不通的是，它找的时候，不是优先找我们的cshtml文件，而是先尝试找了aspx和ascx之类的文件，我们知道这是WebForm里的一套模板。也就是说，如果我们不做任何优化，那么这里的模板查找，总是会在经过几个错误的查找，然后才能找到最终的文件。当然，事先声明，这个查找速度是很快的，影响很小，但是，我还是觉得有必要优化一下，除非我不知道有这么回事。怎么优化？核心就是我们的MVC程序里面其实默认有2套模板引擎，WebForm和Razor，我们看到的aspx之类的就是WebForm在发挥作用，而且它还优先了，这上哪儿说理去。知道这一点，优化也就简单了，如果你用到了WebForm，那么就不要改了，如果你只是用Razor的话，就直接把WebForm删除就好了，删除就是在Global.asax.cs中写：

public class MvcApplication : System.Web.HttpApplication
    {
        // 移除WebFormEngine
        public void removeWebFormEngine()
        {
            var viewEngine = ViewEngines.Engines;
            var webFormEngine = viewEngine.OfType<WebFormViewEngine>().FirstOrDefault();
            if(webFormEngine != null)
            {
                viewEngine.Remove(webFormEngine);
            }
        }

        protected void Application_Start()
        {
            // 移除WebFormEngine
            removeWebFormEngine();
            AreaRegistration.RegisterAllAreas();
            GlobalConfiguration.Configure(WebApiConfig.Register);
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);
        }
    }

现在再启动，然后访问http://localhost:7202/Post的话，就看到模板查找目录和文件相对精准多了，当然理论上将速度也会提高那么一点点点。

“/”应用程序中的服务器错误。
未找到视图“Index”或其母版视图，或没有视图引擎支持搜索的位置。搜索了以下位置: 
~/Views/Post/Index.cshtml
~/Views/Post/Index.vbhtml
~/Views/Shared/Index.cshtml
~/Views/Shared/Index.vbhtml

【5】ASP.NET MVC的程序默认是会把MVC版本号返回给浏览器的，我们可以从下图中看出。如果更改这个默认配置，同样在Global.asax.cs中：

protected void Application_Start()
        {
            // 不要传递mvc版本号给浏览器
            MvcHandler.DisableMvcResponseHeader = true;
            ...
        }