用户的伸手不难梳理,为啥MVC更好有的

MVC架构中,用户的伏乞分为下边一个步骤:

转自http://www.admin10000.com/document/5277.html 

  1. 终极用户发送请求,路由器将请求路由到适当的Controller,Controller是逻辑实体和行为action的汇集。
  2. Controller将请求映射到特定的Action。
  3. action有五个职责,第二是取得合适的数量,第②是将那些多少和视图view绑定起来。action成立数据模型,并将数据模型连接到钦命view,输出最后的应和结果。

前言

  假使你看了近日微软的议程,你会发觉她们未来的点子除了MVC,依旧MVC。难点在于为啥微软如此热衷于遗弃守旧的APS.NET
Webform而转向ASP.NET MVC?本文就根本来商量那几个标题。

 ASP.NET Webform 后台代码(behind code)—— 福音与诅咒

  假设您仔细关怀过ASP.NET
Webform技术,你会发现它更就好像可视化设计,换句话说,开发者只需求从设计面板中拖拽控件即可完结UI,接着在behind
code中达成逻辑代码即可成功最后的Web页面作用。

图片 1

  所以换句话说,当你从筹划面板中拖拽1个按钮时,在后台代码中就会变卦多少个button对象,你只要求在按钮的点击事件中落成事件响应代码即可。

public partial class WebForm1 : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            // Developers write code here
        }

        protected void Button1_Click(object sender, EventArgs e)
        {
            // Developers write code here
        }
    }

  当大家在页面中拖拽一些UI成分时,双击它们即可在后台代码中生成一多元事件响应代码,这个逻辑代码都在ASPX.CS文件中。

图片 2

  那么些后台代码文件是ASP.NET
Webform的重要,你能够在这么些文件中应用.NET的之所以天性,蕴含事件、委托、HTTP协议以及session等等。

  不过那种behind
code方式有四个难点,下边大家将逐一讲述那四个难点,并用MVC的宏图思想来分别化解那个标题。

 难点1:基于视图的方案来缓解基于行为的急需

 我们的网站最终是由用户使用的,用户访问网站肯定会有一定的指标,网站要做的就是透过让用户的相互行为来成功其想要的目标。比如当用户访问三个购物网站时,恐怕她的并行行为会是这么的:

  • 购买产品
  • 打字与印刷发票

  这几个交互行为是经过按钮点击、右键点击和浏览器U昂CoraL达成的。由于这个交互都以依照HTTP协议的,所以若是大家能将这个交互行为映射到实际的某些措施上,那么整个框架结构将会变得简单很多。

  可是微软做不到那般,因为它要贯彻可视化网页编制程序,所以他们最后摘取了依照视图的缓解方案。

图片 3

  从上海教室能够见到,整个请求进度看上去很意外:

  • 用户发起二个HTTP请求,比如HTTP POST / GET
  • IIS服务器将请求映射到视图
  • 视图调用页面包车型地铁生命周期,通过事件驱动,调用合适的相互格局
  • 末段将并行的结果彰显给终端用户

  因为微软一开头就选取了基于视图的设计方案,所以架构本人很难向基于用户交互的布置性思想靠拢。换句话说,当用户产生“购买”请求时,先是访问了视图页面“Shopping.aspx”,后台逻辑代码在“Shopping.aspx.cs”中,页不熟悉命周期中会将页面包车型地铁计量结果回到给用户。

图片 4

  假使选用MVC的牵记,都以依照用户交互行为来说,那么请求流程将会是之类所示:

图片 5

 难题2:坏架构的副效能 —— 紧耦合

  当您选择了二个荒谬的架构之后,今后将会晤世过多难以解决的副成效,在ASP.NET
Webform中就出现了这些题材。就算behind
code后台代码被分开到不一致的文书中,可是ASPX.CS文件和ASPX文件却紧凑的关联在一块儿,这将导致系统的耦合度很高,并且很难解耦和,那是三个很胸闷的标题。

图片 6

  简单地说,大家很难将Customer.aspx.cs和CustomerDetailed.aspx简单地退出开,后台代码已经紧凑地将其捆在一块儿,而且也很难复用。假设我们能够将呼吁先经过action,而各异过视图view,action得到的数目再由控制器决定由哪位view显示,那么请求的流程将会是这么的:

图片 7

  所以大家能够很便宜地控制最后结出是由活动页面展现依然平常页面展现,如下代码:

public ActionResult Index(string DeviceType)
{
           if (viewType == "Mobile")
            {
                return View("MobileView");
            }
            else
            {
                return View("NormalView");
            }
}

 难题3:HTML不是绝无仅有的归来类型

  由于视图view和后台代码behind
code紧凑耦合在一起,所以暗许的回到类型就固定了,都是HTML类型。如若您想更改类型就务须安装Content-type和调用Response.End方法。

  若是大家创立三个Action,再次回到的类型由Action中钦定,系统就能够在同三个action中遵照分裂尺度输出分裂的回到类型。代码如下:

public ActionResult Index(string viewType)
{
            if (viewType == "JSON")
            {
                return Json(new Customer(), JsonRequestBehavior.AllowGet);
            }
            else
            {
                return View("DisplayCustomer", new Customer());
            }
}

 难点4:视图和数码的灵活组合

  Webform是视图优先的架构,所以视图决定了表现的数据,所以视图的扩大性就很差,假设遇上复杂的数据结构,那种艺术就展现心有余而力不足了。

  可是如果是作为事先的框架结构的话,当我们触发action时,action能够遵照不相同的伸手采纳分歧的数据模型和视图结构,如下图:

图片 8

  在MVC中,你能够在分裂的view中挑选相同的数据模型,比如上面的代码,customerdata数据既能够绑定在DetailCustomer视图中,也足以绑定在Customer视图中。

public ActionResult Index(string ViewName,Customer customerdata)
{
            if (ViewName == "Detailed")
            {
return View("DetailCustomer",customerdata);
            }
            else
            {
                return View("Customer",customerdata);
            }
}

  那在Webform中落到实处起来是非凡艰苦的。

 难题⑤ 、将behind code当做普通的类来拓展单元测试

  behind
code后台代码在Webform中是3个不行巨大的类,并且不能够大约地实例化。要掌握Webform是继续于Page类的,Page类无法直接实例化,因为它有太多的注重项了。

public partial class WebForm1 : System.Web.UI.Page
    {
        protected void Page_Load(object sender, EventArgs e)
        {

        }

        public void Button1_Click(object sender, EventArgs e)
        {
            Session["SomeSession"] = "Is this set";
        }
    }

  你干什么想要实例化Page类呢?当中多个缘故正是足以便宜单元测试。比如作者要测试3个按钮点击事件,用来检查Session是或不是设置成功。在Webform中的代码看起来不是那么舒服:

[TestMethod]
public void TestMethod1()
{
            WebApplication22.WebForm1 obj = new WebApplication22.WebForm1();

            obj.Button1_Click(this, new EventArgs());
}

  并且运维时还会抛出三个不行:

图片 9

  在MVC中,那一个类成为了三个普通类,大家能够在测试工程上校它实例化,并对类里面包车型客车品质方法、Session、viewbag
、 tempdata等展开单元测试。

public class HomeController : Controller // ß this class is simple 
{
        public ActionResult Index()
        {
            Session["SomeSession"] = "Is this set";
            return View("SomeView");
        }
}

 所以是不是选拔MVC解决方案?

图片 10

  从Webform架构切换成MVC架构,你供给做以下几件工作:

  • 将behind
    code中的代码转移到controller类中,并将本来的不二法门转换来action方法。
  • 高级中学级层用数据模型和逻辑接口代替。
  • 视图view只用来表现数据和页面布局。
  • DAL层和任何层没有怎么变动,因为它和behind code关系十分的小。

图片 11

  所以MVC框架结构中,用户的呼吁分为下面二个步骤:

  • 终点用户发送请求,路由器将呼吁路由到相当的Controller,Controller是逻辑实体和行为action的聚集。
  • Controller将请求映射到一定的Action。
  • action有七个职分,第2是得到合适的数据,第③是将那么些数据和视图view绑定起来。action创设数据模型,并将数据模型连接到钦命view,输出最终的对应结果。

  英文原版的书文:Webforms vs MVC and Why MVC is better
?
 翻译:codeceo –
小峰