本文将介绍表现层及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/