应用程序框架实战三十:表现层及ASP.NET MVC介绍（一）

　　本文将介绍表现层及ASP.NET MVC的一些要点，特别是ASP.NET MVC的一些抽象和封装技巧，若是你对MVC还不了解，能够参考《ASP.NET MVC4 高级编程》，做者Jon Galloway等，这本书由ASP.NET MVC团队成员编写，至关不错。

表现层的职责

　　表现层的职责是展现和收集数据，将领域层的数据和逻辑展现出来，并收集用户输入的相关信息。

　　搞清楚表现层的职责之后，你就应该清楚，表现层不是你应该编写业务逻辑的地方，这也是分层架构的核心。

　　若是要展现一个计算值，不该该在表现层直接完成计算，相反，由领域层进行计算，表现层直接拿到结果并展现，这样可让表现层代码很是简洁，同时业务逻辑被高度内聚到领域层。

　　不少时候，为了提高用户体验，咱们会在页面上使用Js进行客户端计算，从而得到快速响应，但也致使业务逻辑泄露到Js中。在大多状况下，这是能够接受的，不过在你准备用Js编写这些重复逻辑时，能够先考虑是否可使用Ajax请求服务端完成。每当你须要进行客户端实时计算时，就发送请求给服务端，领域层完成计算，返回结果。

　　尽可能减小业务逻辑副本，当需求变化或发现BUG时，代码同步更轻松。

　　对于管理系统来讲，尽可能让程序员少写Js，尽可能封装和抽象，由于Js是弱类型，没有编译时检查，代码提示很弱，哪怕使用了Resharper，代码提示功能依然不佳，细长的提示滚动条，看得你两眼直冒金星。另外Js不少技巧看上去很怪异，初学者使用这些技巧，Bug率将大幅上升。当项目交给新人维护，长篇的Js更使其痛苦不堪。固然这是给普通团队的建议，少写Js可让你的项目容易维护，高水平团队请忽视。

Mvc介绍

　　MVC是一个表现层架构模式，将表现层分红三个部分，模型、视图和控制器。

　　当Http请求发送到ASP.NET MVC引擎时，MVC引擎查找路由表以决定由哪一个控制器操做来处理这个请求。

　　控制器是一个指挥中心，它调用后端的服务，并将获得的模型交给视图显示。

　　你能够直接在控制器方法中操做DbContext或仓储，并使用Linq语句进行查询。当你逐步意识到控制器代码变得复杂时，能够建立应用层服务来简化表现层。

　　应用服务为表现层提供惟一的API访问点，大幅下降控制器复杂度，控制器的全部操做，都经过应用服务一个明确的API完成，不只操做更规范，并且控制器将变成很薄的一层。

　　控制器的开发要点是，保持尽可能简单，没事少写代码。把你的需求交给应用层服务去实现，你只须要简单调用其接口就好了。

　　模型是指数据与业务逻辑，即领域模型，大部分时候，你能够在MVC视图中直接操做领域实体，视图模型ViewModel不是必须的。不过出于某些缘由考虑，视图中操做的也多是DTO或ViewModel，当界面变得复杂时，经过为特定视图引入专门的ViewModel 能够简化界面开发。

　　你可能已经发现了名目繁多的实体类型：领域实体、DTO、ViewModel、查询实体等，确实让人眼花缭乱，我将在后续用专文讨论，以方便你根据须要取舍。

约定优于配置

　　“约定优于配置”原则，建议你尽可能遵循默认约定，并造成习惯，这样能够大幅下降学习成本和工做量，同时得到更一致的目录结构和代码风格，查找特定类型的文件变得很是容易，可维护性大大提升了，你仅在必要时才须要经过配置来覆盖默认值。

　　“约定优于配置”原则对目录结构和命名产生了深远影响。

　　项目的目录结构相当重要，但大部分程序员对目录结构不太关心，由于建立文件夹没有技术含量，简单的容易被忽视。

　　当你准备修改某个功能时，第一步起码先得找到相关的文件。

　　若是你平时不太注意目录结构的管理，建立文件很随意，随便找个地方就扔进去了，随着项目文件的增多，你的开发工做将会愈来愈乱，当你要找某个文件时，你会在目录树中四处乱点，“哦，不在这，哦，也不在那，哦耶，终于找到了”。

　　当你要找一个控制器时，你会去查找Controllers目录，而不是一个叫ABCD的目录，这就是命名约定。若是存在一个名为TestController的控制器，默认在Views目录中就会有一个Test的目录与之对应，这样在查找控制器对应的视图时就能很是轻松。

　　当你的全部文件都可以根据约定，分门别类的放到清晰命名的目录中时，整个项目的质量将大幅提高。

　　我在封装EasyUi时，把控件Id的命名做了一些约定，好比表格叫grid。这样不少Js回调函数，就能够在内部完成，不须要你手工处理了，若是你遵循这些约定，开发一个简单的EasyUi CRUD操做，基本不须要写Js。

 

　　.Net应用程序框架交流QQ群: 386092459，欢迎有兴趣的朋友加入讨论。

　　谢谢你们的持续关注，个人博客地址：http://www.cnblogs.com/xiadao521/