MVC实用构架实战..docxVIP

MVC实用构架实战：项目结构搭建一、前言在本文中，将使用代码的方式来一一解说各个层次。由于要搭建一个基本完整的结构，可能文章会比较长。另外，本系列主要出于实用的目的，因而并不会严格按照传统的三层那样进行非常明确的层次职能划分。二、需求说明在本系列中，为方便大家理解，将以一个账户管理的小系统来进行解说，具体需求如下：用户信息分主要信息与扩展信息，一个用户可以有（或没有）一个用户扩展信息。 记录用户的登录记录，一个用户可以有多条登录记录，但登录记录所属用户唯一。 一个用户可以有多个角色，一个角色也可以分配给多个用户。 三、架构基础(一) 功能返回值对于一个操作性业务功能（比如添加，修改，删除），通常我们处理返回值的做法是使用简单类型，通常会有如下几种方案：直接返回void，即什么也不返回，在操作过程中抛出异常，只要没有异常抛出，就认为是操作成功了 返回是否操作成功的bool类型的返回值 返回操作变更后的新数据信息 返回表示各种结果的状态码的返回值 返回一个自定义枚举来表示操作的各种结果 如果要返回多个值，还要使用 out 来添加返回参数 这样做有什么不妥之处呢，我们来逐一分析：靠抛异常的方式来终止系统的运行，异常是沿调用堆栈逐层向上抛出的，会造成很大的性能问题 bool值太死板，无法表示出业务操作中的各种情况 返回变更后的数据，还要与原始数据来判断才能得到是否操作成功 用状态码解决了2的问题，但各种状态码的维护成本也会非常高 用枚举值一定程序上解决了翻译的问题，但还是要把枚举值翻译成各种情况的文字描述 ！@#￥%…… 综上，我们到底需要一个怎样的业务操作结果呢？要能表示操作的成功失败（废话） 要能快速表示各种操作场景（如参数错误，查询数据不存在，数据状态不满足操作要求等） 能返回附加的返回信息（如更新成功后有后续操作，需要使用更新后的新值） 最好在调用方能使用统一的代码进行返回值处理 最好能自定义返回的文字描述信息 最好能把返回给用户的信息与日志记录的信息分开 再综上，显然简单类型的返回值满足不了需求了，那就需要定义一个专门用来封装返回值信息的返回值类，这里定义如下：?///?summary ??///业务操作结果信息类，对操作结果进行封装 ??///?/summary ??public?class?OperationResult??{ ??#region?构造函数 ???///?summary ??///初始化一个?业务操作结果信息类?的新实例 ??///?/summary ??///?param?name=resultType业务操作结果类型/param ??public?OperationResult(OperationResultType?resultType) ??{ ??ResultType?=?resultType; ??} ???///?summary ??///初始化一个?定义返回消息的业务操作结果信息类?的新实例 ??///?/summary ??///?param?name=resultType业务操作结果类型/param ??///?param?name=message业务返回消息/param ??public?OperationResult(OperationResultType?resultType,?string?message) ??:?this(resultType) ??{ ??Message?=?message; ??} ???///?summary ??///初始化一个?定义返回消息与附加数据的业务操作结果信息类?的新实例 ??///?/summary ??///?param?name=resultType业务操作结果类型/param ??///?param?name=message业务返回消息/param ??///?param?name=appendData业务返回数据/param ??public?OperationResult(OperationResultType?resultType,?string?message,?object?appendData) ??:?this(resultType,?message) ??{ ??AppendData?=?appendData; ??} ???///?summary ??///初始化一个?定义返回消息与日志消息的业务操作结果信息类?的新实例 ??///?/summary ??///?param?name=resultType业务操作结果类型/param ??///?param?name=message业务返回消息/param ??///?param?name=logMessage业务日志记录消息/param ??public?Oper