asp.net-mvc - MVC 中 "Master Page"逻辑应该放在哪里？

Question

我正在尝试 MVC，我的问题是 - 我在带有 WebForms 的母版页中使用 Page_Load 逻辑，它应该在 MVC 中的什么位置？以下是业务案例:

• 不同的主机 header 应导致网站的(一个)母版页(即所有页面)上显示不同的页面标题。例如，如果主机 header 为 hello.mydomain.com，则所有页面/ View 的页面标题应为“Hello World”，而所有页面/ View 的 goodbye.mydomain.com 应为“Goodbye World”。
• 如果主机 header 与列表中的任何内容不同，无论应用程序中的哪个位置，它都应该重定向到/Error/NoHostHeader。

以前，我将其放在 MasterPage Load() 事件中，看起来在 MVC 中，我可以在每个 Controller 中执行此操作(感觉必须在每个 Controller 中调用此功能是不对的)，或者 Global.asax 中的某个地方(看起来太……全局？)。

编辑:我已经使用 Global.asax 方法与 Controller 相结合来成功地工作来实际处理数据。此时唯一的问题是，所有主机头信息都在数据库中。如果您愿意，我通常会将“租户”信息存储在 session 变量中，并且仅在该信息不存在时才进行数据库调用；有更好的方法吗？

Answer 1

出于某种原因，MVC 中没有 1:1 的等价物，让我们概括一下如何以 MVC 方式思考它:

模型:“此站点的页面始终在特定上下文中被请求，我们将其称为租户(或用户、主题或子域代表的任何内容)。域模型有一个属性代表当前请求的租户。”

View :“根据模型中设置的租户呈现页面标题。”

Controller :“根据主机 header 在模型中设置租户”。

请记住，我们要避免的是混合 Controller 、 View 和业务逻辑。将 Controller 逻辑放在多个地方或一个地方(不称为“ Controller ”)不是问题，只要它保持分离即可。

现在有一件好事:即使使用 Web 表单，您也可以实现这种“MVC 风格”，并且该解决方案仍然适用于 ASP.NET MVC!

您仍然拥有请求生命周期(而不是页面生命周期)，因此您可以实现一个自定义 HttpModule，其中包含所有请求的这部分 Controller 逻辑。它处理 BeginRequest 事件，检查主机 header ，并将租户存储到类似 HttpContext.Current.Items["tenant"] 的内容。 (当然，您可以为这个字典条目提供一个静态的、类型化的包装器。)

然后您的所有模型对象(或模型基类，或适合您的解决方案的任何内容)都可以访问 HttpContext 以提供对此信息的访问，如下所示:

public string Tenant
{
    get { return HttpContext.Current.Items["tenant"]; }
}

优点:

• 您已将原因(主机 header )和结果(呈现页面标题)分开，从而提高了可维护性和可测试性
• 因此，您可以根据此状态轻松向域模型添加其他行为，例如根据当前租户从数据库加载内容。
• 您可以轻松地使 View 的更多部分取决于租户，例如您包含的 CSS 文件、 Logo 图像等。
• 您稍后可以更改 Controller 逻辑，以便不仅基于子域，还可以基于 cookie、引荐来源网址、搜索词、用户代理的语言或任何您能想到的内容来设置模型中的租户，而无需根据模型修改任何代码。

更新您的编辑:我不喜欢在 session 中保留状态的想法，特别是如果您的 session cookie 可能不仅适用于每个子域，而且适用于所有域。在这种情况下，如果用户之前访问过另一个子域，您可能会提供不一致的内容。数据库中将主机 header 映射到租户的信息可能不会经常更改，因此您可以缓存它，并且不需要为每个请求进行数据库查找。