Webforms vs MVC，为什么MVC更好?

内容先决条件介绍 ASP。NET Webform背后的代码-福利和诅咒问题1:-基于行动的需求的基于视图的解决方案问题2:-不良架构的副作用:-紧密耦合问题3:- HTML不是唯一的响应类型问题4:视图和数据的灵活组合问题5:-使后面的代码成为单元测试的普通类所以解决方案是MVC? 我们失去了什么? 父亲的请求感谢我的女儿Sanjana创造了这张图片。如果你能在FB https://www.facebook.com/photo.php?这将有助于她将来成为一名漫画家。我只是想告诉她，她在绘画方面有多好，应该把它作为职业道路来考虑。顺便说一句，上面的图片将帮助你可视化为什么MVC比webforms更好。当你阅读这篇逐步学习MVC的文章之前，这个图像将帮助你连接在一起。先决条件在本文中，我将使用两个经常使用的术语。NET Web表单和ASP。净MVC。许多开发人员认为ASP。NET不同于MVC。但事实上MVC是一种架构编码风格，而ASP。净框架。如果你来自认为ASP的类别。NET和MVC是不同的，所以我诚实的建议是首先阅读这篇文章，以避免任何进一步的混乱http://computerauthor.blogspot.in/2014/08/aspnetvs-mvc-vocabul-confusion_15.html 介绍如果你看一下微软最近的议程，你会清楚地看到他们主要关注的是MVC, MVC和MVC。所以问题是，为什么微软如此热衷于抛弃像ASP这样成功的东西。并说服微软web开发社区使用asp.net Webform。净MVC。这就是本文所关注的。 ASP。NET Webform背后的代码-福利和诅咒如果你仔细观察ASP。这是一种用于web开发的RAD /可视化方法。换句话说，开发人员拖放设计器上的用户控件和后面代码中的VS工具代码。换句话说，当你在设计器上拖放按钮控件时，一个按钮对象就被创建了，开发人员可以在按钮对象的单击事件中编写代码。隐藏,复制Code

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部分类文件中巧妙地和安静地。现在这部分代码文件是成功交付ASP的关键。NET Webformprojects的开发速度更快，封装了大量的技术细节，如事件、委托、HTTP协议POST、GET、会话管理等。你可能会想阅读这篇文章为什么Microsoft有分部类?以及Microsoft UI的成功故事。但是由于后面代码的定位和调用方式，它有5个严重的问题。因此，让我们来讨论这5个问题，以及MVC如何帮助解决这些问题。问题1:-基于行动的需求的基于视图的解决方案网站在一天结束时被最终用户使用。最终用户带着特定的目的来到一个网站，他们通过行动来传达他们的目的。例如，如果有人来购物门户，他将交流他的目的使用行动:- 购买产品。打印发票现在这些动作是通过点击按钮、右键或通过浏览器URL等来传达的。基于这种基于动作的结构，Web选择了HTTP协议，因为它具有POST、GET、PUT、DELETEetc等动作，可以更清楚地传达终端用户的意图。这也使得REST成为处理最终用户请求的流行方式。因此，从逻辑上讲，如果我们能将这些动作映射到程序的方法/函数，那将更有意义，也能保持架构简单。但是微软没有办法，他们想要支持RAD概念，或者我们可以称之为可视化编程概念，所以他们最终为基于动作的结构提供了基于视图的解决方案。所以对于web表单(如上图所示)，请求流变得很奇怪:- 最终用户通过HTTP POST / GET等操作发送请求。IIS webserver将这个请求映射到一个视图。视图调用页面生命周期，遍历事件，然后调用适当的操作。最后，action put将结果以HTML格式发送给最终用户浏览器。最后，微软为基于动作的需求提供了基于视图的架构。因此，架构本身在逻辑上并不适合最终用户的基于操作的方法。换句话说，如果最终用户发送了一个“购买”动作，它首先会出现一个类似“购物”的视图。aspx，谁反过来踢“购物。aspx。执行一个复杂的页面生命周期，然后执行将满足最终用户的要求的操作。这就像击中要害。在一个复杂的页面生命周期之后，end请求被映射到实际的操作就完成了。所以，我们应该让以行动为导向的建筑师，而不是以视图为导向的建筑师。或者我可以换一种说法“我们如何使行动优先而不是视图优先?” 先点击动作，然后动作会抓取视图。这将使流程更有逻辑和清晰。这正是MVC架构所做的。第一次命中是一个属于控制器的操作，然后控制器用适当的模型调用视图。问题2:-不良架构的副作用:-紧密耦合一旦你以一个错误的架构开始，你最终会调整事情，然后你会以严重的副作用结束。在这个案例中，同样的事情发生了。背后的代码在不同的文件中看起来是不同的，但实际上却从来没有解耦过，比如ASPX. cs不能与ASPX分离。简单地说，我无法附加“Customer.aspx”。cs”与“CustomerDetailed。aspx”很容易。后面的代码与视图紧密耦合。它是不可重用的。如果你曾经分析过背后代码的数量w.r。对于这个项目的其他层次来说，它的规模是巨大的，有着复杂的事件。从长期的角度来看，这使得代码难以阅读和维护。因此，如果我们能将视图第一基于的架构改变为操作第一基于的架构，那么我们就能在不同的视图中重用相同的操作代码。例如，如果终端用户发送一个动作“Display”，它可以调用“DisplayDesktop”。aspx”或者它可以显示“DisplayMobile”。aspx "取决于设备的类型。所以在MVC操作取决于情况，我们可以调用“MobileView”或“NormalView”，下面是相同的样例代码。想象一下在Webform后面的代码中实现这个，非常困难，对吧。隐藏,复制Code

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

问题3:- HTML不是唯一的响应类型由于视图和代码之间的紧密耦合，甚至响应类型在webform中都是固定的，所以默认是HTML。如果您希望更改它，则需要使用Content-type和“Response”。结束“方法等，安静乏味。如果我们先创建"行动"结构那么行动就有足够的空间来决定应该采取什么样的反应类型。这使得我们的系统在相同的动作和不同的输出方面更加灵活。下面是一个简单的MVC操作代码，根据传递给操作的值发送JSON或HTML结果。webformview很难实现这种灵活性，因为它们只能发出HTML。隐藏,复制Code

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

问题4:视图和数据的灵活组合当我们向用户发送响应时，它是视图(显示)和数据(模型)的组合。Webform是一个视图优先的架构，因此视图决定连接哪个模型，这使得视图不那么灵活，也涉及到复杂的决策制定。这显然违反了SOLID原则的SRP，请在这里阅读更多关于SOLID原则的内容。但是，如果我们采用“行动第一”架构，那么首先出现的是“行动”，他选择模型和视图来发送不同的响应。在MVC操作中，您可以编写如下所示的代码。你可以拿起同一个模型，然后用不同的视角将它连接起来。例如，在下面的代码中，我们采用了“customerdata”模型并附加了“DetailCustomer”视图，而相同的模型在其他情况下附加了“Customer”视图。隐藏,复制Code

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

通过Webform实现这种灵活性是非常困难的，因为调用是在视图本身上进行的，然后需要在页面生命周期中编写所有决策制定逻辑，并重定向到其他视图，这样实现就不那么清晰了。问题5:-使后面的代码成为单元测试的普通类 webform背后的代码是一个非常典型的笨重的部分类，它不能直接用简单的c#代码实例化。请记住，Webform屏幕继承自“Page”类。这个页面类不能直接创建，因为它有很多依赖项。隐藏,复制Code

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类。我希望实例化这个page类的地方之一是用于单元测试。我想调用按钮点击方法的动作，测试会话变量是否设置正确，视图状态是否正确等等。但是，如果您尝试像下面代码中所示那样做，您将以如下所示的奇怪代码结束。注意那些传递给按钮单击方法的难看的事件参数。隐藏,复制Code

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

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

当你调用它时，它要求更多的东西，这使得UI单元测试不可能。在MVC中，这就变成了一个普通的类。一个可以在简单的单元测试项目中实例化的类，你可以用一种简单的方式测试各种方面，比如session,viewbag, tempdata。隐藏,复制Code

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

所以解决方案是MVC? 从基于视图的架构到ac加强基于MVC架构我们需要做以下结构变化(上图给出了可视化视图相同的):- 后面的代码移动到一个控制器类与所有的事件转换方法可称为行动。中间层成为模型提供数据和业务逻辑。视图只显示,定位和布局。木豆和其他层不改变很多,因为他们没有直接与后台代码的问题。所以与MVC架构我们有以下三个步骤流程:- 最终用户应用程序发送他的请求。应用程序将请求路由到控制器。控制器是一个逻辑实体,团体一起行动。控制器将请求映射到一个特定的行动。现在行动有两个任务首先需要访问适当的数据取决于行动和第二数据必须连接到正确的观点。操作创建模型对象并将模型视图发送最终的响应。我们宽松的什么? ASP的最大优势。净WebForm RAD /可视化编程。尽管它是一个快速和肮脏的做事的方法能帮助你更快地完成应用程序,让你的客户感到满意和按时交货。你可以阅读本文讨论将在http://www.codeproject.com/Articles/808297/Things-you-will-miss-in-ASP-NET-MVC-as-an-ASP-NET MVC小姐的Webforms的决定是正确的方式在2000年对微软,因为它想迁移VB6, VF, vc++开发人员他们都沉迷于RAD编程。我认为Webform已经实现了的目标是创建现在朝着更好的和逻辑架构即MVC。如果你确信MVC的办法你可以学习MVC 2天即16小时使用下面的视频。也从Web表单与MVC文章阅读和学习。本文转载于：http://www.diyabc.com/frontweb/news1855.html

Webforms vs MVC，为什么MVC更好?

相关推荐