我们这里的图形化元素是指开发工具给我们提供的控件和工具集合我们通过这些图形化元素设计出与用户交互的界面我们希望我们的表现层能够在不同的控件上可以以不同的方式表现出来我们同时希望图形化元素中的任意修改不会影响到表现层逻辑举个例子我们平时在博客园中的模板设计其实就是个很好的例子我们选择不同的模板我们的博客页面就会在皮肤样式主题等方面都发生变化但是并不影响我们的表现层。4.2、UI层与表现层逻辑4.2.1、用户界面的职责我们接下来看看UI层的相关职责我们知道我们平时在系统设计过程中一般架构师不会直接参与到用户的界面的设计中架构师更侧重系统的可用性和可访问性。我们认为UI层的主要功能包括下面几项下面我们来分别说说吧1、数据显示我们都知道UI层是用户使用系统的唯一入口那么首先用户界面必须将系统中的一些信息进行展示这些信息可能包括普通信息、提示信息、系统中的相关数据信息等良好的设计UI能够很好的展示数据用户界面需要支持本地化及全球化功能。2、友好的交互交互就体现在用户使用系统的功能这样就会有这样的操作用户输入相应的数据通常来说一个好的UI层会提供给用户一个比较人性化的输入页面并且会根据用户的输入返回用户想得到的结果。不管UI层的具体技术是什么好的用户交互页面都是系统中最重要的部分。输入的数据我们如何做到安全性方面的验证是我们必须重视的部分。3、总体外观系统的功能都是通过用户界面来作为统一入口提供给用户使用的所以一般来说我们在设计UI时必须要有精致的用户界面软件的目的就是抓住用户能够给用户较好的用户体验而且根据软件的用户群来进行不同的设计如果是提供给大众使用的软件那么我们必须达到设计精致的用户界面的要求如果是提供给企业内部使用那么我们可以注重功能而不是视觉效果的震撼当然不是说不重视UI只是没有那么重视。4.2.2、表现层中容易产生的误区我们来看看我们平时在表现层的设计与实现过程中可能存在的误区吧我们来看看每个误区的说明吧1、过度依赖工具自从有了Visual Studio 开发工具以来就因为其提供了大量的控件为我们开发简单的应用程序提供了很大的方便我们通常都是通过拖拽控件来完成UI层的设计。我们通过一些带有事件的控件去完成与其他层之间的交互我们可以在事件中直接处理逻辑而且很方便很快捷。这也使得我们的开发效率很高当然这是开发简单的应用程序时我们通过这样来做没有什么问题。但是当我们开发大型的企业级应用时这样的方式可能就不是理想的选择了为什么这么说呢我们不是说不用开发工具提供的控件而是应该将职责进行划分比如说用设计器完成界面的设计然后其他的代码都是通过我们的手工边写而不是通过开发工具提供的一些控件去完成比如说Visio Studio 提供的数据源绑定控件等而且如何将事件中的代码进行更好的抽象就是我们这里的需要考虑的问题。2、表现层的边界我们先要清楚表现层的职责是什么它主要负责什么我们知道表现层中的UI层是个很薄弱的层UI层应该只负责与用户进行交互表现层逻辑应该负责协调数据流入/流出UI层那么这里的表现逻辑层应该具有什么样的功能。我们在前面介绍业务逻辑层中也提到过我们有时候将业务逻辑放在表现层中也是可以接收的还是看具体的系统需要。有的时候我们很钟爱把业务逻辑层中的功能反正表现层逻辑中我自己的很多项目中也是这样做的因为我目前的项目中也有这样的代码充斥者我们说过这不是万恶的但是当系统有一定规模时表现逻辑层就会变成一个无所不有无所不包的容器难以维护和测试。通过上面的分析我们知道我们还是需要根据系统的实际需要来决定是不是把一些业务逻辑写在表现逻辑层中对于大型的企业级项目来说我们必须考虑这些问题因为好的设计可以提供测试行维护性等我们对表现逻辑层的要求也会比较高我们期望通过SOC来实现我们一般是通过分层来实现因为分层来分离功能点我们通过分离关注点可以提供表现逻辑层的重构提醒更好的设计结构和代码结构提高复用性。3、WUGWYW大家估计出一看还以为是什么意思呢原谅我这里卖了个关子意思就是说(what–user-get-is-what-you-want)用户得到的就是你想要的。我们在使用图形化的界面设计工具时为了能更好的提供开发效率现在很多的开发工具提供了界面预览的功能基本上是所见即所得但是并不是全部例如Visio Studio 提供的web开发中的预览但是有时候我们还需要自己动手去处理一些表现层的东西所以我们会对界面通过CSS去控制UI层的显示我这里解释这个的意思就是有时候我们需要多写一些代码来提供更好的功能满足用户的需求。4.3、MVC模式的提出及演化从本节开始我们就开始对表现层中的模式进行讲解我们主要是针对MVC模式的起源及发展过程进行讲解。4.2.2、MVC模式(Model-View-Controller)MVC模式起源于上个世纪80年代目前已经有了30年的历史了在现在的今天可能我们没有办法再使用原来的定义去完成表现层的设计了但是我们现在使用的MVC模式都是从原来的MVC模式中演变过来的以适应目前的软件开发需求。我们这里可能说的MVC模式也不是原始的定义包括后面介绍的MVP模式等。我们这里需要知道表现层都有哪些分类每种分类可能演变出哪些哪些分类等这对我们对表现层的模式有个大概的结构对我们对表现层的设计有很大的帮助下面我们来看看吧:我们将会详细的讲解这些模式及应用本节将详细的讲解MVC的演变及原理其中由MVC模式演变的Model2模式正式目前ASP.NET MVC的实现方式。在早起我们开发表现层的时候我想我们更多的是将表现层逻辑与视图放在一个文件中可以看作是功能自治的视图。用户与视图交互视图负责捕获用户的输入信息并在内部处理然后更新自己或者跳转到另外一个视图。这样的组织形式不但难以维护更难测试因此更加让大家渴望有一种好的模式从这样复杂的表现层中分离出来由此MVC模式便提出来了。MVC模式的提出将我们从视图自治的设计方式脱离出来自治的视图内部的处理可能包含业务层数据访问层或者服务层等等当然还有自身的设计层。MVC模式则让我们把自治视图的功能进行分离将自治视图分解成视图层控制层模型的形式来分离关注点通过关注点的分离来降低系统的复杂度进而提供系统的更好的设计性。那么MVC模式也有人称作模范那么MVC到底是模式还是模范呢我们来看看模式与模范的定义吧可能就更能理解MVC了模式在软件领域中是指一个被证明过的具体的某类问题的解决方案。模范是指某一类相似问题的解决方案一般是指一类相似的模式。通过上面的解释我们知道MVC是模式。我们来看看自治视图与MVC的结构上的区别MVC模式我们知道将自治视图中的功能进行分离分离成功能相对独立的组件并且通过这些组件的交互完成表现层的工作。可