开发日志

开发日志

ASP.NET MVC是一种非常反人类的设计。（我没有接触过Java的MVC，不知道两者是否一样。如果一样，那么搞Java的同学也挺可怜。）尤其是MVC的路由机制，灰常灰常反动。路由所带来的“美观的”URL，通过合理的文件层次布局+URL重写机制同样可以解决。但显然文件目录结构的方式，更直观明了，贴近人们的自然思路。可惜不管我们如何吐槽，萨蒂亚•纳德拉估计是不会听的。

　　MVC的默认组织机构是扁平的。所有的Controller都是平级的。在大型项目中，这完全是一个灾难。当需要上百个甚至数百个Controller，或是为了让代码“自说明”时（指合理的给方法、文件命名，使阅读者在没有注释的时候也能直接读懂开发者的意图），很多Controller需要同名时，尤其让人崩溃。路是死的，人是活的。为了解决这一问题，聪明的程序猿想出了很多办法。比如利用Area机制、重写视图匹配机制、重写MVC框架等等。我们的OA系统中也有近百个Controller，不提前规划好路由，后续的工作我们就无法展开。所以，在这一节，我们就来聊聊其中两种不对MVC做大手术的方式。

（仅仅一个小功能模块就需要10多个Controller，在大型项目中，甚至需要数百个Controller，对项目管理而言，如不进行合理划分、管理，而按照mvc默认的平级存放，无疑会带来灾难性的后果。注：本图已对功能模块进行按目录划分）

MVC大型项目常见组织方式1——重写视图匹配机制，实现MVC多级目录

 　　该方式的核心要点是：根据功能划分，对Controller和View进行多级目录处理（如上图）。然后通过路由优先级和重载MVC自带的视图匹配逻辑的方式，达到精确控制URL与Controller、Views进行匹配。进行这是最接近自然思维的处理方式，合理而精细的安排路由优先级的情况下，可以做到非常深的目录层次。在我们的示例项目中，也将采用这种办法。

1. 根据功能划分，对Controller和View进行多级目录划分。
2. 注册路由列表，通过优先级的方式，将路由和Controller一一对应。
3. 重载MVC视图匹配逻辑，将View和Controller一一对应。

　　

 1 namespace EasyFast.Web
 2 {
 3     public class RouteConfig
 4     {
 5         public static void RegisterRoutes(RouteCollection routes)
 6         {
 7             routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
 8 
 9             //ASP.NET Web API Route Config
10             routes.MapHttpRoute(
11                 name: "DefaultApi",
12                 routeTemplate: "api/{controller}/{id}",
13                 defaults: new { id = RouteParameter.Optional }
14                 );
15 
16             routes.MapRoute(
17                 name: "Default",
18                 url: "{controller}/{action}/{id}",
19                 defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional },
20                 namespaces: new string[] { "EasyFast.Web.Controllers" }
21             );
22         }
23     }
24 }

 1 namespace EasyFast.Web.Areas.Admin
 2 {
 3     public class AdminAreaRegistration : AreaRegistration 
 4     {
 5         public override string AreaName 
 6         {
 7             get 
 8             {
 9                 return "Admin";
10             }
11         }
12 
13         public override void RegisterArea(AreaRegistrationContext context) 
14         {
15             context.MapRoute(
16                 "Admin_Config",
17                 "Admin/Config/{controller}/{action}/{id}",
18                 new { action = "Index", id = UrlParameter.Optional }
19             );
20             context.MapRoute(
21                 "Admin_default",
22                 "Admin/{controller}/{action}/{id}",
23                 new { action = "Index", id = UrlParameter.Optional },
24                 new string[] { "EasyFast.Web.Areas.Admin.Controllers" }
25             );
26         }
27     }
28 }

　　如上代码所示。我们给 App_Start->RouteConfig.cs 文件增加了namespace参数，并指定了完整的命名空间 “EasyFast.Web.Controllers” 。在一个MVC应用中，指定了该命名空间后，就可以解决Areas和站点根目录中有重名的Controller问题。如站点首页是HomeController，后台首页也是HomeController此时MVC会检测到两个重名的控制器，系统会要求给其中一个控制器指定完整命名空间。我们的一般做法是给App_Start文件中的路由配置文件指定命名空间。否则我们就必须为每个Areas指定命名空间（其他Areas里也可能有叫HomeController的控制器）。当然了，您也可以给App_Start和所有的Areas中的路由都指定命名空间，但是，只指定App_Start->RouteConfig.cs无疑是一种简洁的做法。

　　细心的朋友可能会看到：我们给App_Start->RouteConfig.cs和Areas.Admin.AdminAreaRegistration.cs都指定了命名空间。这是因为在我们的Admin区域下。也会有多个重名的控制器（例如HomeController）。同时，要注意：有目录划分的路由要写在默认路由的前面，且不可和默认路由重名。

（同一个Areas里出现两个同名的HomeController控制器。系统设置这个模块的首页和后台首页控制器重名。只要涉及到控制器重名，就必须给其中一个指定完整命名空间）

 1 namespace EasyFast.Web.Extend
 2 {
 3     public class EasyFastViewEngine : RazorViewEngine
 4     {
 5         public EasyFastViewEngine()
 6         {
 7             ViewLocationFormats = new[]
 8             {
 9                 "~/Views/{1}/{0}.cshtml",
10                 "~/Views/Shared/{0}.cshtml",
11                 "~/Views/Areas/{1}/{0}.cshtml"//我们的规则
12             };
13             AreaViewLocationFormats = new[]
14             {
15                 "~/Areas/{2}/Views/{1}/{0}.cshtml",
16                 "~/Areas/{2}/Views/Shared/{0}.cshtml",
17 
18                 "~/Areas/{2}/Views/Config/{1}/{0}.cshtml",
19                 "~/Areas/{2}/Views/User/{1}/{0}.cshtml",
20                 "~/Areas/{2}/Views/Case/{1}/{0}.cshtml",
21 
22                 "~/Areas/{2}/Views/Config/Shared/{0}.cshtml",
23                 "~/Areas/{2}/Views/User/Shared/{0}.cshtml",
24                 "~/Areas/{2}/Views/Case/Shared/{0}.cshtml"
25             };
26         }
27 
28         public override ViewEngineResult FindView(ControllerContext controllerContext, string viewName, string masterName, bool useCache)
29         {
30             return base.FindView(controllerContext, viewName, masterName, useCache);
31         }
32 
33         public static void Config()
34         {
35             ViewEngines.Engines.Clear();
36             ViewEngines.Engines.Add(new EasyFastViewEngine());
37         }
38     }
39 }

 1 namespace EasyFast.Web
 2 {
 3     public class MvcApplication : AbpWebApplication<EasyFastWebModule>
 4     {
 5         protected override void Application_Start(object sender, EventArgs e)
 6         {
 7             AbpBootstrapper.IocManager.IocContainer.AddFacility<LoggingFacility>(
 8                 f => f.UseAbpLog4Net().WithConfig("log4net.config")
 9             );
10             EasyFastViewEngine.Config();//注册多级目录扩展
11             base.Application_Start(sender, e);
12         }
13     }
14 }

　　如上代码。我们在web根目录下建立了Extend文件夹，并在其中新建了EasyFastViewEngine.cs文件。然后再文件内部，重载了MVC自带的视图查找逻辑。代码中的{2}、{1}、{0}是占位符，分别代表了Area、Controller、Action。这样一来，程序在实行时就会按照我们制定的查找顺序去指定的目录匹配View文件。通过合理的路由安排，这样做可以做到很深的目录层次结构。相信聪明的读者一定想到了如何扩展出三级、四级甚至更多级的目录。

　　如此做法，本身也存在一定的不便。在具体Action上右键选择转到视图，或是在具体视图右键选择控制器时，VS会提示找不到对应的控制器或是视图。但这不是MVC的问题，而是VS自身的问题，VS在设计时应该没考虑过多级目录问题。同时，在Ctrl+F5运行程序时，浏览器会直接按照文件路径加载对应的cshtml文件，并报404错误。此时，需要我们手动修改URL路径，程序就能正常显示了。

（在具体View页面直接编译运行程序时，会显示404错误，此时手动修改URL地址即可解决）

MVC大型项目常见组织方式2——前后台独立，利用Area划分功能区域

　　该方式不用对MVC做任何定制修改。只需要在项目架构里将前台、后台、用户中心等划分成多个web项目即可。然后在每个web项目里，根据功能群的划分，再独立建立Areas。如此做法，有三个直观的好处同样也有三个直观的缺陷。因为好处和缺陷都是同样显而易见，我们就不一一详细介绍了，只列出总结的提醒，供大家选择判断。

好处：

1. 不用对MVC框架做任何调整，可以方便的从视图或是控制器自由切换。
2. 多个web项目意味着可以生成多份程序，可以分别部署到不同的服务器上，以提高站点负载。
3. 团队开发时，不同的项目可以交付不同的开发人员，最大程度上避免沟通成本。

坏处：

1. 最大只能做到三级目录。（其实这不算什么坏处，三级目录对一个大中型项目来说，是足够用的，如感觉不够用，更多的应该考虑如何合并功能群而不是拓展更深的目录层次）。
2. 共享与资源锁问题。几乎在所有的应用程序中，都有前后台公用的css、js、配置文件甚至代码段本身等等等等，当前后台独立时，就需要为这些需要共享资源安排合适的位置而头疼了。在例如在实现内存缓存时，我们都要求缓存类是单例的，但是，单例是应用程序范围内的单例。前台和后台分别部署，显然是两个应用程序，代码中的单例缓存类也就彻底失效了。
3. 部署问题。任意修改非web项目后，都需要多次部署。如再考虑上CDN或是缓存服务器什么的，部署将会更加麻烦。

 1         public long Add(UserTypeInput model)
 2         {
 3             long _result = 0;
 4             var data = Mapper.Map<UserTypeInput, Core.Entities.UserType>(model);
 5             lock (lockHelper)
 6             {
 7                 if (!CheckName(model))
 8                 {
 9                     _result = _userTypeRepository.InsertAndGetIdAsync(data).Id;
10                     
11                 }
12             }
13             return _result;
14         }

　　考虑如上代码。假设前后台都调用Add方法时，lock控制段显然会失效。这样一来，新增数据时，重名检测方法会失效，有可能会造成前后台分别录入了一条重名的人员类别。

（前后台分属不同的项目，利用Area实现系统设置、案件管理、用户管理等功能群，此做法只能实现三级目录，功能群模块（具体Area）/功能组（Controller）/具体功能(Action)）