MVC2，MVC3，MVC4和MVC5的不同

MVC2，MVC3，MVC4和MVC5的不同：

1、查看引擎:

视图引擎负责将HTML代码从视图呈现到浏览器。

MVC 2仅使用Web窗体视图引擎( .aspx)作为默认视图引擎。

MVC3使用剃刀视图引擎( .c#和的cshtml。vbhtml (用于Visual Basic )和Web窗体视图引擎( .阿斯佩克斯)。

MVC4还使用剃刀视图引擎作为默认视图引擎，具有一些新功能，如条件属性和“波形斜线”。

2、图表、网络网格、加密、网络映像、网络邮件控制:

所有这些在MVC2中都不可用。

所有这些都在MVC3和MVC4中提供。

3、合成语法：

Web窗体视图引擎语法: <% = HTML代码%>在MVC2中。

(剃刀语法)剃刀视图引擎语法: @MVC3中的Html代码。

MVC4具有相同的剃刀视图引擎语法，但添加了新功能，如条件属性和“波形斜线”，即URL解析。

4、可用于在视图和控制器之间共享数据的对象:

模板数据、视图数据在MVC2中可用。

MVC3中提供了临时数据、视图数据、视图包。

MVC4中提供了临时数据、视图数据、视图包。

>TempData用于当前和后续请求，即当您知道要重定向的下一个视图时。

>在ViewData中，可以通过字符串作为键访问对象字典。

>在c#4.0中添加了ViewBag，它使用允许动态添加对象属性的动态功能。我们可以说ViewBag = ViewData +ViewData字典周围的动态特性。

5、jquery支持:

jquery支持在MVC2中很好。

在MVC3中，jquery支持更好。

MVC4为Jquery (如Jquery Mobile)提供了更好的支持。

6、验证:

MVC2中有客户端验证和异步控制器。

MVC3中包含不引人注目的Ajax和客户端验证、Jquery验证和JSON绑定支持。

客户端验证、Jquery验证和对MVC4异步方法的增强支持。

7、项目模板:

MVC3支持由HTML5启用的项目模板。

MVC4支持移动应用程序的许多新功能，还提供了新的移动项目模板和更新和现代化的默认模板。

8、ASP.NET MVC 5中的新功能:

（1）一个ASP网；

（2）ASP净身份；

（3）MVC模板中的引导程序；

（4）认证过滤器；

（5）过滤器覆盖。

MVC简介：

MVC，全名是Model View Controller，是软件工程中的一种软件架构模式，把软件系统分为三个基本部分：模型(Model)、视图(View)和控制器(Controller)，具有耦合性低、重用性高、生命周期成本低等优点。

MVC用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

框架内容：

MVC是一个框架模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。最典型的MVC就是JSP+servlet+javabean的模式。

作者：oec2003

公众号：不止dotNET

微服务或许你没有真正实践过，但一定听说过，虽然已经到了 2022 年，这个词依然很热，可以通过搜索 google 指数看得到。

“微服务”一词源于 2011 年 5 月在威尼斯附近的一次软件架构师研讨会上进行的架构风格的讨论。2012 年 5 月 讨论小组决定将这种架构风格命名为“微服务”。Fred George 同年在一次技术大会上进行自己的微服务实践分享，并说微服务是一种细粒度的 SOA ，但最终将其发扬光大的是 Martin Fowler 2014 年写的博文《 Microservices 》，原文链接如下：

https://martinfowler.com/articles/microservices.html

自此以后，微服务就家喻户晓了，Microservices 的 Google 指数也是在 2014 年后就一路飙升。

和微服务相对应的是单体架构，先来看看单体架构是怎样的。

大多数人做软件开发应该都是从单体架构开始的，以 .NET 程序员来说，从最早的 WebForm、到后来的 MVC、再到现在的前后端分离，后端使用 .NET 的 WebAPI ，都是整个项目的代码放到一个解决方案中，发布要么直接整个目录进行替换，或者更新有变更的 dll 文件。

包括到现在，这种单体架构的模该还占着很大的比重，凡是存在，必有道理，单体架构有着他的可取之处：

不过，随着产品的功能越来越复杂，代码也会变得越来越复杂，团队的人数也会越来越多，这时单体架构就会带来一些问题：

上面提到的单体架构存在的问题，采用微服务架构可以很好地解决。微服务的核心是为了解耦，构建成一个松耦合的分布式系统。

一个庞大的单体系统拆分成若干个小的服务，每个服务可以由一个小的团队来维护，团队会更加敏捷，构建发布的时间更短，代码也容易维护。

不同的微服务团队可以采用不同的技术栈，比如工作流引擎使用 .NET ，规则引擎可以使用 Java ，一些全新的模块更容易采用新的技术，人员流动和补充上也更加灵活。

每个服务通常采用独立的数据库，代码或者数据库层面的问题不会导致整个系统的崩溃。

扩展方便，这个很重要，如果监控发现流程引擎的压力很大，可以只针对这个服务进行横向扩展，服务器资源可以得到更好的利用。

上面说的都是好处，但没有任何一种技术是银d，微服务解决问题的同时，也会带来更多的问题。

1、开发调试变得困难了，需要通过日志的方式或者借助一些远程调试工具；

2、单体架构中，模块之间的调用都是进程内，添加类库的引用后，就是本地方法的调用，微服务各自独立部署，就会涉及到进程间的通信；

3、线上问题往往需要多个服务团队一起来协作解决，会存在互相甩锅的问题；

4、在分布式系统中，事务、数据一致性、联合查询等相比较单体更加复杂；

5、持续集成、部署、运维的复杂度也显著提升；

6、随着服务越来越多，客户端怎样去找这些服务呢？

7、进程内的访问不存在网络的问题，拆分后的服务可能在同个机器的不同进程，更多的时候是不同机器的不同进程，网络问题导致服务不稳定怎么办？

为了解决这些问题，各种中间件和框架就应运而生，又会带来更多的学习成本。

在 .NET 技术栈中，会用到下面这些中间件：

在 Java 中也有 Spring Cloud 和 Spring Cloud Alibaba 这种全家桶套件可以使用。

从单体到微服务是一个权衡和取舍的问题，切记不要跟风。以我的经验来看，可以分为两类：

1、做企业级系统；

2、做互联网系统。

做企业级应用大多都是项目交付型的，客户关系维系的好，后面可以做二期、三期，当然也有一锤子买卖的。这其中一个关键点是要快，单从快速来看，采用单体架构，开发、调试、部署都是最快的。

从客户角度来说，只要能满足业务，是单体还是微服务其实不太关心。

做互联网应用，也就是我们常说的 SaaS，也分为两种情况：

1、将现有的私有化部署的系统（单体架构）改造成支持 SaaS 的模式。

这种我也不建议一上来就大刀阔斧地进行微服务改造，可以在代码的结构上做一些调整，比如按照领域去拆分目录，不同领域之间的调用可以再进行一层抽象，目的是为了未来向微服务架构转化。

当团队的技术栈变得丰富了，比如原先只有 .NET ,现在有些模块采用的是 Java ,这时已然是朝着微服务架构发展了，只是粒度比较大而已，相应的一些中间件也需要引入，比如服务网关、服务发现、服务间通信等。

2、从零开始做一个 SaaS 系统。

即便因为时间关系，一开始是单体架构，我觉得也应该是微服务架构的单体，随着持续迭代和发展，根据实际情况逐步进行拆分。

如果时间上比较充裕，可以一开始就按照微服务架构进行分离，但粒度不要太小。

1、解决常说的的三高问题（高并发、高性能、高可用），一个核心的思路就是拆，分而治之，所以说微服务肯定是能解决掉我们的很多问题，也是发展方向；

2、实践微服务需要根据当前的实际情况，如果单体运行的很好，也没什么问题，也不要为了炫技进行微服务改造；

3、如果决定要实践微服务，先做好单体架构的设计，让代码遵循面向对象的设计原则，否则即便形式上变成了微服务，也不能尝到微服务的甜头。

ASXH是一般的网站应用程序，主要用来处理小型的，不需要回发的请求，比如发送个图片给客户端啊，这种。他不是一个项目，而是一个项。只要是ASP.NET项目中，都可以右键添加一个asxh项，用于url处理请求。

优点是很简单，缺点是很老很过时，至于以后和其他客户端交互更是难，因为asxh项是很难维护成一个系统的服务的。

主流的处理方式是使用WebService， WebService可以用于处理后台需要的业务逻辑、数据交互并且依托IIS来发布出去。一般主流的.NET网站，大部分都使用WebService或者WebApi来进行服务发布，然后前端使用MVC进行开发（你使用html+js+ajax其实都是视图UI，而前端可能还需要一些其他的东西来进行网站和服务的交互，比如MVC的控制器，或者webform的后台代码，纯js和服务交互在.NET中并不好用）。

因为WebService使用XML来进行数据交互，基本上所有的客户端都可以调用其服务，包括安卓和IOS。

WebService学起来很简单， 就是将服务端需要的所有逻辑、数据代码封装好，然后发布即可。

---