2. it
  3. 使用Micrisoft.net设计方案 第三章Web表示模式 Web模式集群详细介绍 Front Controller（前端控制器）...

使用Micrisoft.net设计方案 第三章Web表示模式 Web模式集群详细介绍 Front Controller（前端控制器）...

mac2022-06-30  96

已经决定使用Model-View-Controller (MVC) 模式将动态 Web 应用程序的用户界面逻辑与业务逻辑分隔开来。您已经考察了Page Controller模式，但您的页面控制器类具有复杂的逻辑，并且是较深的继承层次结构的一部分，或者，您的应用程序是基于可配置的规则来动态确定页面导航的。

如何为非常复杂的 Web 应用程序构建最佳的控制器结构，以便在避免代码重复的同时实现重用性和灵活性？

下面是适用于 Front Controller 模式的、由 Model-View-Controller 带来的各种具体的影响因素：

1、如果在系统的不同视图内复制公共逻辑，则需要集中此逻辑才能减少代码重复量。删除重复的代码是改进系统的总体可维护性的关键。

2、数据检索最好也集中在一个位置进行处理。一个好的示例是，让一系列视图使用数据库中的相同数据。与让每个视图检索数据并重复数据库访问代码相比，在一个位置实现对此数据的检索是更好的做法。

如 MVC 中所述，测试用户界面代码往往是耗时而乏味的。通过区分单各自的角色，可以提高总体可测试性。这不仅适用于模型代码（在 MVC 中已说明），而且适用于控制器代码。

以下影响因素可能使您决定使用 Front Controller，而不是 Page Controller。

1、Page Controller 的一般实现方法涉及为各个页面所共享的行为创建一个基类。但是，随着时间的推移，由于要增加非所有页面公用的代码，这些基类就会不断增大。若需要定期重构此基类以确保其只包括公共行为，则需要制定规则。例如，您不希望由页面检查请求并决定（基于请求参数）是否将控制权转移给另一个页面，因为这种类型的决定对于特定功能来说更具体，而不是所有页面共有的。

2、为了避免在基类中添加过多的条件逻辑，您会创建更深的继承层次结构以删除条件逻辑。例如，在具有三个功能区域的应用程序中，只使用一个包含应用程序公共功能的基类可能是很有用的。每个功能区域可能还有另一个类，该类 继承总体应用程序的基类。乍一看，这种类型的结构是简单的，但它通常会导致非常脆弱的设计和实现，并给代码带来问题。

3、Page Controller 解决方案描述了每个逻辑页面使用一个对象。当需要跨多个页面对处理过程进行控制或协调时，此解决方案将不可行。例如，假定在 Web 应用程序中具有复杂的可配置导航（以 XML 格式存储）。当收到请求时，应用程序必须根据其当前状态查找下一步要前进到哪个位置。

4、由于Page Controller 是通过每个逻辑页面使用一个对象来实现的，因此，很难在 Web 应用程序的所有页面中一致地应用特定操作。例如，安全性最好以协调方式实现。让每个视图或页面控制器对象分别处理安全性是有问题的，因为它可以被不一致地应用，并导致安全问题。此问题的其他解决方案还将在Intercepting Filter 中进行讨论。

5、对于 Web 应用程序来说，URL 与特定控制器对象的关联可以是强制性的。例如，假定您的站点具有类似向导的界面用于收集信息。此向导包括许多必备页面和许多基于用户输入的可选页面。在使用 Page Controller 实现时，必须使用基类中的条件逻辑来实现可选页面，才能选择下一页面。

解决方案

Front Controller 通过让单个控制器负责传输所有请求，从而解决了在 Page Controller 中存在的分散化问题。控制器本身通常分为以下两部分实现：处理程序和命令层次结构（见图 1）。

图 1:Front Controller 结构

处理程序具有以下两项职责：

检索参数。处理程序接收来自 Web 服务器的 HTTP Post 或 Get 请求，并从请求中检索相关参数。选择命令。处理程序首先使用请求中的参数选择正确的命令，然后将控制权转移给该命令以便执行处理。

图 2 显示这两项职责。

图 2:Front Controller 的典型方案

命令本身也是控制器的一部分。命令代表具体的操作，这在 Command 模式中有相应的介绍。通过将命令表示为单独的对象，控制器可以按一般方式与所有命令交互，这与调用公共命令类上的特定方法相反。在命令对象完成操作之后，将由命令选择使用哪个视图来显示页面。

Front Controller 模式具有下列优缺点：

优点

集中化控制。 Front Controller 用于协调向 Web 应用程序发出的所有请求。此解决方案描述了使用单一控制器，而不是 Page Controller 中所用的分布式模型。此单一控制器处于很好的位置来实施全应用程序范围的策略，如安全性和使用情况跟踪。线程安全。由于每个请求都涉及创建新的命令对象，因此命令对象本身不需要是线程安全的。这意味着，命令类中避免了线程安全问题。但是，这并不意味着您可以完全避免线程问题，因为命令所作用的代码（即模型代码）仍然必须是线程安全的可配置性。只需要在 Web 服务器中配置一个前端控制器；处理程序执行其余的调度。这简化了 Web 服务器的配置。一些 Web 服务器是很难配置的。

缺点

性能考虑事项。 Front Controller 是用来处理对 Web 应用程序的所有请求的单个控制器。在这两部分中，应该仔细检查处理程序中是否有性能问题，因为处理程序将确定负责执行请求的命令的类型。如果处理程序必须执行数据库查询或 XML 文档查询才能作出决定，则可能导致性能非常缓慢。增加了复杂性。 Front Controller 比 Page Controller 更复杂。它通常涉及将内置控制器替换为自定义的 Front Controller。实现此解决方案会增加维护成本和新手的学习难度。

测试考虑事项

从视图中删除业务逻辑简化了视图的测试难度，因为此后可以在独立于控制器的情况下测试视图。

在ASP.NET中使用HTTPHandler实现Front Controller

实现策略

Front Controller 通常分为两个部分来实现。Handler 对象从 Web 服务器接收各个请求（HTTP Get 和 Post），并检索相关参数，然后根据参数选择适当的命令。控制器的第二个部分是 Command Processor，该部分执行特定操作或命令来满足请求。命令完成后转到视图，以便显示页面。

注意：此实现策略解决了前面的示例中出现的问题。虽然此示例可能不足以证明对 Front Controller 的更改是合理的，但它说明了为什么会使用 Front Controller ，并且该实现解决了这种复杂性高得多的问题。另外，与大多数实现一样，实现此模式的方式不止一种，这只是其中的一个选择。

处理程序

ASP.NET 提供低级请求/响应 API 来处理传入的 HTTP 请求。ASP.NET 所接收的每个传入 HTTP 请求最终由实现 IHTTPHandler 接口的类的具体实例来处理。这种低级 API 非常适用于实现 Front Controller 的处理程序部分。

图 1 显示了控制器的处理程序部分的结构。

图 1 Front Controller 的处理程序部分

此解决方案完美地划分了职责。Handler 类负责处理各个 Web 请求，并将确定正确的 Command 对象这一职责委派给 CommandFactory 类。当 CommandFactory 返回 Command 对象后，Handler 将调用 Command 上的 Execute 方法来执行请求。

Handler.cs

下面的代码示例显示了如何实现 Handler 类：

using System;

using System.Web;

public class Handler : IHttpHandler

{

   public void ProcessRequest(HttpContext context) 

   {

      Command command = 

         CommandFactory.Make(context.Request.Params);

      command.Execute(context);

   }

   public bool IsReusable 

   { 

      get { return true;} 

   }

}

Command.cs

Command 类是 Command 模式的一个示例。Command 模式在此解决方案中非常有用，因为您不希望 Handler 类直接依赖于命令。一般来说，可以从 CommandFactory 返回命令对象。

using System;

using System.Web;

public interface Command

{

   void Execute(HttpContext context);

}

CommandFactory.cs

CommandFactory 类对于实现至关重要。它根据查询字符串中的参数来判断将创建哪个命令。在此示例中，如果 site 查询参数被设置为 micro 或根本没有设置，工厂将创建 MicroSite 命令对象。如果 site 被设置为 macro，工厂将创建 MacroSite 命令对象。如果该值被设置为任何其他值，工厂将返回 UnknownCommand 对象，以便进行默认错误处理。这是 Special Case 模式的一个示例。

using System;

using System.Collections.Specialized;

public class CommandFactory

{

   public static Command Make(NameValueCollection parms)

   {

      string siteName = parms["site"];

      Command command = new UnknownCommand();

      if(siteName == null || siteName.Equals("micro"))

         command = new MicroSite();

      else if(siteName.Equals("macro"))

         command = new MacroSite();

      return command;

   }

}

配置处理程序

HTTP 处理程序在 ASP.NET 配置中被声明为 web.config 文件。ASP.NET 定义了一个可以在其中添加和删除处理程序的 <httphandlers> 配置段。例如，ASP.NET 将 Page*.aspx 文件的所有请求映射到应用程序的 web.config 文件中的 Handler 类：

<httpHandlers>

   <add verb="*" path="Page*.aspx" type="Handler,FrontController" />

</httpHandlers>

命令

命令代表了网站中的可变性。在此示例中，从每个站点的数据库中检索数据的功能包含在它自己的类中，并且该类是从名为 RedirectingCommand 的基类继承而来的。RedirectingCommand 类实现了 Command 接口。调用 RedirectingCommand 类的 Execute 时，它首先调用名为 OnExecute 的抽象方法，然后转到视图。该特定视图是从名为 UrlMap 的类检索而来的。UrlMap 类从应用程序的 web.config 文件中检索映射关系。图 2 显示了该解决方案的命令部分的结构。

图 2 front controller 的命令部分

RedirectingCommand.cs

RedirectingCommand 是一个抽象基类，它调用名为 OnExecute 的抽象方法来执行特定命令，然后转到从 UrlMap检索到的视图。

using System; using System.Web; public abstract class RedirectingCommand : Command {    private UrlMap map = UrlMap.SoleInstance;    protected abstract void OnExecute(HttpContext context);    public void Execute(HttpContext context)    {       OnExecute(context);       string url = String.Format("{0}?{1}",          map.Map[context.Request.Url.AbsolutePath],          context.Request.Url.Query);       context.Server.Transfer(url);    } } UrlMap.cs UrlMap 类从应用程序的 web.config 文件加载配置信息。配置信息将所请求的 URL 的绝对路径关联到该文件所指定的另一个 URL。这样，就可以更改当请求外部页面时要将用户转到哪个实际页面。这个过程为更改视图提供了很高的灵活性，因为用户永远不会引用实际页面。下面是 UrlMap 类： using System; using System.Web; using System.Xml; using System.Configuration; using System.Collections.Specialized; public class UrlMap : IConfigurationSectionHandler  {    private readonly NameValueCollection _commands = new NameValueCollection();    public const string SECTION_NAME="controller.mapping";    public static UrlMap SoleInstance     {       get {return (UrlMap) ConfigurationSettings.GetConfig(SECTION_NAME);}    }    object IConfigurationSectionHandler.Create(object parent,object configContext, XmlNode section)     {       return (object) new UrlMap(parent,configContext, section);       }    private UrlMap() {/*no-op*/}    public UrlMap(object parent,object configContext, XmlNode section)     {       try        {          XmlElement entriesElement = section["entries"];          foreach(XmlElement element in entriesElement)           {             _commands.Add(element.Attributes["key"].Value,element.Attributes["url"].Value);          }       }        catch (Exception ex)        {          throw new ConfigurationException("Error while parsing configuration section.",ex,section);       }    }       public NameValueCollection Map    {       get { return _commands; }    } } 下面的代码是从显示配置的 web.config 文件中摘录的： <controller.mapping>    <entries>       <entry key="/patterns/frontc/3/Page1.aspx" url="ActualPage1.aspx" />       <entry key="/patterns/frontc/3/Page2.aspx" url="ActualPage2.aspx" />    </entries> </controller.mapping> 

MicroSite.cs

MicroSite 类与此模式前面的 LoadMicroHeader 中的代码类似。主要区别是，无法再访问页面中包含的标签。而必须将信息添加到 HttpContext 对象。下面的示例显示了 MicroSite 代码：

using System;

using System.Web;

public class MicroSite : RedirectingCommand

{

   protected override void OnExecute(HttpContext context)

   {

      string name = context.User.Identity.Name;

      context.Items["address"] = 

         WebUsersDatabase.RetrieveAddress(name);

      context.Items["site"] = "Micro-Site";

   }

}

MacroSite.cs

MacroSite 类与 MicroSite 类似，但它使用的是不同的数据库网关类 MacroUsersDatabase。这两个类都将信息存储在传递进来的 HttpContext 中，以便让视图可以检索它。下面的示例显示了 MacroSite 代码：

using System;

using System.Web;

public class MacroSite : RedirectingCommand

{

   protected override void OnExecute(HttpContext context)

   {

      string name = context.User.Identity.Name;

      context.Items["address"] = 

         MacroUsersDatabase.RetrieveAddress(name);

      context.Items["site"] = "Macro-Site";

   }

}

WebUsersDatabase.cs

WebUsersDatabase 类负责从“webusers”数据库中检索电子邮件地址。它是 Table Data Gateway [Fowler03] 模式的一个示例。

using System;

using System.Data;

using System.Data.SqlClient;

public class WebUsersDatabase

{

   public static string RetrieveAddress(string name)

   {

      string address = null;

      String selectCmd = 

         String.Format("select * from webuser where (id = '{0}')",

         name);

      SqlConnection myConnection = 

         new SqlConnection("server=(local);database=webusers;Trusted_Connection=yes");

      SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, myConnection);

      DataSet ds = new DataSet();

      myCommand.Fill(ds,"webuser");

      if(ds.Tables["webuser"].Rows.Count == 1)

      {

         DataRow row = ds.Tables["webuser"].Rows[0];

         address = row["address"].ToString();

      }

      return address;

   }

}

MacroUsersDatabase.cs

MacroUsersDatabase 类负责从“macrousers”数据库中检索电子邮件地址。它是 Table Data Gateway 模式的一个示例。

using System;

using System.Data;

using System.Data.SqlClient;

public class MacroUsersDatabase

{

   public static string RetrieveAddress(string name)

   {

      string address = null;

      String selectCmd = 

         String.Format("select * from customer where (id = '{0}')",

         name);

      SqlConnection myConnection = 

         new SqlConnection("server=(local);database=macrousers;Trusted_Connection=yes");

      SqlDataAdapter myCommand = new SqlDataAdapter(selectCmd, myConnection);

      DataSet ds = new DataSet();

      myCommand.Fill(ds,"customer");

      if(ds.Tables["customer"].Rows.Count == 1)

      {

         DataRow row = ds.Tables["customer"].Rows[0];

         address = row["email"].ToString();

      }

      return address;

   }

}

视图

视图最后实现。“更改需求”中的示例视图负责根据用户访问哪个站点从数据库中检索信息，然后向用户显示所产生的页面。因为数据库访问代码已移到命令，所以视图现在从ttpContext 对象检索数据。图 3 显示了代码隐藏类的结构。

图 3 视图的代码隐藏类的结构

由于仍然存在公共行为，因此仍然需要 BasePage 类以避免代码重复。

BasePage.cs

与“更改需要”中的示例相比，BasePage 类已有大幅更改。它不再负责确定要加载哪个站点头信息。它只检索由命令存储在 HttpContext 对象中的数据，并将它们分配给适当的标签：

using System; using System.Web.UI; using System.Web.UI.WebControls; public class BasePage : Page {    protected Label eMail;    protected Label siteName;    virtual protected void PageLoadEvent(object sender, System.EventArgs e)    {}    protected void Page_Load(object sender, System.EventArgs e)    {       if(!IsPostBack)       {          eMail.Text = (string)Context.Items["address"];          siteName.Text = (string)Context.Items["site"];          PageLoadEvent(sender, e);       }    }    #region Web Form Designer generated code    #endregion }

ActualPage1.aspx.cs 和 ActualPage2.aspx

ActualPage1 和 ActualPage2 是针对具体页面的代码隐藏类。它们都是从 BasePage 继承而来的，以确保在屏幕的顶部填入头信息：

using System; using System.Web.UI; using System.Web.UI.WebControls; public class ActualPage1 : BasePage {    protected System.Web.UI.WebControls.Label pageNumber;    protected override void PageLoadEvent(object sender, System.EventArgs e)    {       pageNumber.Text = "1";    }    #region Web Form Designer generated code    #endregion } using System; using System.Web.UI.WebControls; public class ActualPage2 : BasePage {    protected Label pageNumber;    protected override void PageLoadEvent(object sender, System.EventArgs e)    {       pageNumber.Text = "2";

   }

  #region Web Form Designer generated code

   #endregion

}

在从 Page Controller 实现转移到 Front Controller 实现时，不必更改这些页面。

测试考虑事项

实现对 ASP.NET 运行库的依赖性使测试变得很困难。您无法将通过继承 System.Web.UI.Page 、 System.Web.UI.IHTTPHandler 或 ASP.NET 运行库中所包含的其他各种类而得到的类进行实例化。这就无法对应用程序的大多数组成部分分别进行单元测试。自动测试此实现的所选方法是，生成 HTTP 请求，然后检索 HTTP 响应，并确定响应是否正确。此方法容易产生错误，因为这是在将响应文本与预期文本进行比较。

CommandFixture.cs

对于可测试的实现来说，导致其可测试的一个因素是 CommandFactory，因为它是独立于 ASP.NET 运行库的。因此，您可以通过编写测试步骤来验证是否获得了正确的 Command 对象。下面是 CommandFactory 类的 NUnit (http://nunit.org) 测试：

using System; using System.Collections.Specialized; using NUnit.Framework; [TestFixture] public class CommandFixture {    private static readonly string microKey = "micro";    private static readonly string macroKey = "macro";    [SetUp]    public void BuildCommandFactory()    {       NameValueCollection map = new NameValueCollection();       map.Add(microKey, "MicroSite");       map.Add(macroKey, "MacroSite");    }    [Test]    public void DefaultToMicro()    {       NameValueCollection map = new NameValueCollection();       Command command = CommandFactory.Make(map);       Assertion.AssertNotNull(command);       Assertion.Assert(command is MicroSite);    }    [Test]    public void MicroSiteCommand()    {       NameValueCollection map = new NameValueCollection();       map.Add("site", "micro");       Command command = CommandFactory.Make(map);       Assertion.AssertNotNull(command);       Assertion.Assert(command is MicroSite);    }    [Test]    public void MacroSiteCommand()    {       NameValueCollection map = new NameValueCollection();       map.Add("site", "macro");       Command command = CommandFactory.Make(map);       Assertion.AssertNotNull(command);       Assertion.Assert(command is MacroSite);    }    [Test]    public void Error()    {       NameValueCollection map = new NameValueCollection();       map.Add("site", "xyzcommand");       Command command = CommandFactory.Make(map);       Assertion.AssertNotNull(command);       Assertion.Assert(command is UnknownCommand);    } }

可以通过进一步的工作来隔离 Command 类。Execute 方法的一个参数是 HttpContext 对象。您可以更改此参数，使该对象独立于 ASP.NET 环境。这样，您就可以在 ASP.NET 运行库之外对命令进行单元测试。

实现 Front Controller 增加了复杂性，并导致了许多优缺点：

优点

提高了灵活性。该实现展示了如何通过 Handler 类集中和协调所有请求。Handler 使用 CommandFactory 来确定要执行的具体操作。这样，就可以在不更改 Handler 类的情况下修改和扩展功能。例如，要添加另一个站点，则必须创建特定命令，并且唯一必须更改的类是 CommandFactory。简化了视图。Page Controller 示例中的视图从数据库检索数据，然后产生页面。在 Front Controller 中，视图不必再依赖数据库，因为这项工作是由各个命令来完成的。可以扩展， 但不能修改。该实现为进行多种形式的调度提供了许多机会。例如，无论执行什么方法和对象，Handler 只调用 Command 对象的 Execute 方法。因此，您可以在不修改 Handler 的情况下添加额外的命令。通过用其他工厂代替 CommandFactory，可以对该实现进行进一步扩展。URL 映射。UrlMap 允许让用户看不到实际的页面名。用户输入一个 URL，然后系统将使用 web.config 文件将它映射到特定的 URL。这可以让程序员有更大的灵活性，因为这样做可以获得 Page Controller 实现中所没有的一个间接操作层。线程安全。命令对象（MicroSite 和 MacroSite）是针对每个请求分别创建的。这意味着，您不必担心这些对象中的线程安全问题。

缺点

性能降低。您必须检查是否有这样的可能。所有请求都是通过 Handler 对象处理的。它使用 CommandFactory 来确定要创建哪个命令。虽然在本示例中没有性能问题，但应该仔细检查这两个类，看看是否存在任何潜在的性能问题。其他方面的问题。该实现比 Page Controller 复杂得多。该实现的确提供了更多选择，但它的代价是复杂性和许多类。您必须权衡是否值得采用该实现。在您采用该实现并构建了框架后，可以很容易地添加新的命令和视图。不过，由于 Page Controller 是在 ASP.NET 中实现的，与在其他平台上相比，Front Controller 的实现不会同样多。测试考虑事项。由于 Front Controller 是在 ASP.NET 中实现的，因此很难单独测试。要提高可测试性，应该将要测试的功能从依赖于 ASP.NET 的代码中分离到不依赖于 ASP.NET 的类中。然后，您不必启动 ASP.NET 运行库就可以测试这些类。无效的 URL。因为 Front Controller 根据输入参数和应用程序的其他当前状态来决定要转到哪个视图，因此，URL 可能不会总是转到同一个页面。这样就会让用户无法保存 URL，也就无法随后再访问该页面。

转载于:https://www.cnblogs.com/ljf10223063/p/4609431.html

最新回复(0)