架构

MVC

MVC，顾名思义，Model、View、Controller。所有的 界面代码放在View里面，所有涉及和界面交互以及URL路由相关的逻辑都在Controller里面，Model提供数据模型。MVC的架构方式会让系 统的可维护性更高，使得每一部分更加专注自己的职责，并且MVC提供了强大的路由机制，方便了页面切换和界面交互。然后可以结合和WebForm的比较， 谈谈MVC如何解决复杂的控件树生成、如何避免了复杂的页面生命周期。
MVC(Model View Controller)模型——视图——控制器；
模型负责业务领域的事情，视图负责显示的事情，控制器把数据读取出来填充模型后把模型交给视图去处理。而各种验证应该是在模型里处理了。它强制性的使应用程序的输入、处理和输出分开。MVC最大的好处是将逻辑和页面分离；

● Model (模型) - 包含 BLL、DAL。View 和 Controller 都依赖于 Model，但是 Model 既不依赖于 View，也不依赖于 Controller，这是分离的主要优点之一
● View (视图) - 仅负责生成输出 (UI)。以 ASP.NET MVC 来说，不再有 Code-behind 这种 .aspx.cs 文件，亦无 runat=“server” 标记、form 标记、控件声明、事件处理
● Controller (控制器) - 控制整个系统的 workflow、运作逻辑、错误处理、身分验证和授权、用户输入数据验证、…等等

列举ASP.NET MVC ActionResult的返回值有几种类型？

主要有View（视图）、PartialView（部分视图）、Content（内容）、Json（Json字符串）、Javascript（js脚本）、File（文件）等几种类型。

简述ASP.NET WebApi相对于ASP.NET MVC的优点？

WebApi消息处理管道独立于ASP.NET平台，支持多种寄宿方式。

什么是MVC中的Razor?
它是一个轻量级的视图引擎。MVC最初只有一个ASPX的视图类型，直到MVC3才引进了Razor ,将原来的aspx文件改为了cshtml文件
ASPX:<%=DateTime.Now%>
Razor: @DateTime.Now

三层架构

表现层(UI)、业务逻辑层(BLL)、数据访问层(DAL)。目的即为了“高内聚，低耦合”的思想；

表现层(UI)：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候的所见所得；

业务逻辑层(BLL)：业务层一般分为二层，业务表观层实现与表示层的沟通，业务规则层实现用户密码的安全等；

表示层：为了与用户交互例如用户添加表单针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理；

数据访问层(DAL)：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等；

每层之间是一种垂直的关系；

三层结构是N层结构的一种，一般来说，层次之间是向下依赖的，下层代码未确定其接口(契约)前，上层代码是无法开发的，下层代码接口(契约)的变化将使上层的代码一起变化；

优点：分工明确，条理清晰，易于调试，而且具有可扩展性；

缺点：增加成本；

DDD

DDD是一种开发理念，核心是维护一个反应领域概念的模型（领域模型是软件最核心的部分，反应了软件的业务本质），然后通过大量模式来指导模型设计与开发。
DDD的一般过程是：首先通过软件需求规格说明书或原型生成一个领域模型（类、类的属性、类与类之间的关系）；然后根据模式（应该如何分层？、领域逻辑写在哪？与持久化如何交互？如何协调多对象领域逻辑？如何实现逻辑与数据存储解耦等）指导来实现代码模型。
DDD核心思想是由业务问题来控制解决方案的形式从以数据库为中心过渡到领域模型为中心

表现层（Presentation Layer）：图中的用户界面层包括用户接口层，用户输入和数据展示。
应用层（Application Layer）：应用层定义系统的业务功能，并指挥领域层中的领域对象实现这些功能。业务逻辑，数据传输对象DTO定义，AutoMapper进行实体与DTO之间的映射等
领域层（Domain Layer）：核心层，实现所有业务逻辑。实体，仓储，领域服务等
基础设施层（Infrastructure Layer）：提供整个业务系统的基础服务。ORM框架支持，DB Migrations等

DDD的好处：
DDD能应对复杂性与快速变化：
1.从技术维度实现分层：能够在每层关注自己的事情，比如领域层关注业务逻辑的事情，仓储关注持久化数据的事情，应用服务层关注用例的事情，接口层关注暴露给前端的事情。
2.业务维度：通过将大系统划分层多个上下文，可以让不同团队和不同人只关注当前上下文的开发。
3.时间维度：通过敏捷式迭代快速验证，快速修正。

DDD里面几个比较重要的概念：
1.界限上下文：

首先要将大系统划分层多个界限上下文，比如大健康行业直销系统可以划分为产品、经销商、订单等几个界限上下文，每个界限上下文有自己的领域逻辑、数据持久化、用例、接口等。每个界限上下文根据特点，具体实现方式又不同，比如有些界限上下文基本没有业务逻辑，就是增删改查，则可以使用CRUD最简单的模式；有些界限上线文有一定的业务逻辑，但对高并发、高性能没要求，则可以使用经典DDD模式；有些界限上下文有一定的业务逻辑，而且有高性能要求，则可以使CQRS模式。

2.实体：

有业务生命周期，采用业务标识符进行跟踪。比如一个订单就是实体，订单有生命周期的，而且有一个订单号唯一的标识它自己，如果两个订单所有属性值全部相同，但订单号不同，也是不同的实体。

3.值对象：

无业务生命周期，无业务标识符，通常用于模式实体。比如订单的收货地址、订单支付的金额等就是值对象。

4.服务：

无状态，有行为，通常就是一个用例来协调多个领域逻辑完成功能。

5.聚合：

通常将多个实体和值对象组合到一个聚合中来表达一个完整的概念，比如订单实体、订单明细实体、订单金额值对象就代表一个完整的订单概念，而且生命周期是相同的，并且需要统一持久化到数据库中。

6.聚合根：

将聚合中表达总概念的实体做成聚合根，比如订单实体就是聚合根，对聚合中所有实体的状态变更必须经过聚合根，因为聚合根协调了整个聚合的逻辑，保证一致性。当然其他实体可以被外部直接临时查询调用。

7.服务：

协调聚合之间的业务逻辑，并且完成用例。

8.仓储：

用于对聚合进行持久化，通常为每个聚合根配备一个仓储即可。仓储能够很好的解耦领域逻辑与数据库。

9.工厂：

用于创建复杂的领域对象，能够将领域对象复杂的创建过程保护起来。

详细解释

1、领域模型：领域模型与数据模型不同，它表述的是领域中各个类及其之间的关系。从领域驱动设计的角度看，数据库只不过是存储实体的一个外部机制，是属于技术层面的东西。数据模型主要用于描述领域模型对象的持久化方式，应该是先有领域模型，才有数据模型，领域模型需要通过某种映射而产生相应的数据模型，从这点来说，最新的EF的Code First就是一个很好的体现。领域模型对象分为实体、值对象和服务。
2、实体：在领域驱动设计里面，实体是模型中需要区分个体的对象。这里的实体和EntityFramework里面的实体不是一个概念，EF的实体为数据实体，不包含对象的行为。就博主的理解，DDD概念里面的实体就是包括实体数据(EF的Model)和行为的结合体。
3、值对象：通过对象属性值来识别的对象，它将多个相关属性组合为一个概念整体。相比实体而言，值对象仅仅是比实体少了一个标识。值对象的设计比较存在争议，我们暂且记住值对象和实体的区别：（1）实体拥有唯一标识，而值对象没有；（2）实体允许变化，而值对象不允许变化；（3）判断两个实体相等的方法是判断实体的标识相等，而判断两个值对象相等的标准是值对象内部所有属性值相等；
4、聚合（以及聚合根）：聚合表示一组领域对象(包括实体和值对象)，用来表述一个完整的领域概念。而每个聚合都有一个根实体，这个根实体又叫做聚合根。举个简单的例子，一个电脑包含硬盘、CPU、内存条等，这一个组合就是一个聚合，而电脑就是这个组合的聚合根。博主觉得关于聚合的划分学问还是挺大的，需要在实践中慢慢积累。同一个实体，在不同的聚合中，它可能是聚合根，也可能不是，需要根据实际的业务决定。聚合根是聚合所表述的领域概念的主体，外部对象需要访问聚合内的实体时，只能通过聚合根进行访问，而不能直接访问。
5、领域服务：博主的理解，领域模型主张富领域模式，也就是说把领域逻辑尽量写在领域实体里面，也就是常说的“充血模式”，而对于业务逻辑，最好是以服务的形式提供。至于领域逻辑和业务逻辑的界定，这个要根据实际情况来定。总之，领域服务是用来处理那些领域模型里面不好定义或者某些可变逻辑的的时候才会用到。

ABP

ABP是为新的现代Web应用程序使用最佳实践和使用最流行工具的一个起点。可作为一般用途的应用程序的基础框架或项目模板。它的功能包括：

服务器端：

基于最新的.NET技术 （目前是ASP.NET MVC 5、Web API 2、C# 5.0，在ASP.NET 5正式发布后会升级）
实现领域驱动设计（实体、仓储、领域服务、领域事件、应用服务、数据传输对象，工作单元等等）
实现分层体系结构（领域层，应用层，展现层和基础设施层）
提供了一个基础架构来开发可重用可配置的模块
集成一些最流行的开源框架/库，也许有些是你正在使用的。
提供了一个基础架构让我们很方便地使用依赖注入（使用Castle Windsor作为依赖注入的容器）
提供Repository仓储模式支持不同的ORM（已实现Entity Framework 、NHibernate、MangoDb和内存数据库）
支持并实现数据库迁移（EF 的 Code first）
模块化开发（每个模块有独立的EF DbContext，可单独指定数据库）
包括一个简单的和灵活的多语言/本地化系统
包括一个 EventBus来实现服务器端全局的领域事件
统一的异常处理（应用层几乎不需要处理自己写异常处理代码）
数据有效性验证（Asp.NET MVC只能做到Action方法的参数验证，ABP实现了Application层方法的参数有效性验证）
通过Application Services自动创建Web Api层（不需要写ApiController层了）
提供基类和帮助类让我们方便地实现一些常见的任务
使用“约定优于配置原则”

客户端：

Bootstrap、Less、AngularJs、jQuery、Modernizr和其他JS库: jQuery.validate、jQuery.form、jQuery.blockUI、json2等
为单页面应用程序（AngularJs、Durandaljs）和多页面应用程序（Bootstrap+Jquery）提供了项目模板。
自动创建Javascript 的代理层来更方便使用Web Api
封装一些Javascript 函数，更方便地使用ajax、消息框、通知组件、忙状态的遮罩层等等

除ABP框架项目以外，还开发了名叫“Zero”的模块，实现了以下功能：

身份验证与授权管理（通过ASP.NET Identity实现的）
用户&角色管理
系统设置存取管理（系统级、租户级、用户级，作用范围自动管理）
审计日志（自动记录每一次接口的调用者和参数）