MVC - 谁格式化模型？

Question

在渲染到视图模型之前，应格式化：

1. 多语言数据本地化;
2. 日期，时间值格式化;
3. 数字格式。

谁执行所有这些格式化 - 控制器或视图？

我是否正确所有格式化都由Controller执行，它创建了仅包含格式化值的所谓ViewModel并将此ViewModel发送到View？

提前致谢！

Answer 1

Eric Petroelje是对的，但我会建立一个帮助类来获取本地化的内容/日期等，因为本地化并不总是在视图中，例如发送包含本地化内容的电子邮件我会有类似LocalisationHelper.GetString（“MyKey”）或LocalisationHelper.GetDate（Date.Now）的东西，其中LocalisationHelper知道用户当前的区域设置（可能来自Session）。

然后在可能的情况下直接在视图中使用它：

<%= Html.Encode(LocalisationHelper.GetDate(Date.Now)) %>

Answer 2

设计模式101。

模型用于存储数据（通常是数据库支持的）。

查看用于展示数据（不操纵数据）。

控制器用于操作模型并将其传递给视图（例如，选择正确的区域设置将在此处）。

MVC 并不一定意味着您有3个不同的类，而是3个组件或层。这些是抽象的，不一定要绑在一个物理类上。在Controller层中，可以包含任意数量的辅助类或其他类型。

我同意cartoonfox所说的一部分，一切都是交织在一起的。例如，如果您为购物车开发视图，但模型包含生日信息，那么它将不起作用。它只是一种帮助消除重复工作的设计模式。当您拥有较少的变量和较少的噪音时，可以更加轻松地关注需要完成的工作并更好地理解它。

我与我们的团队讨论了如何使用注释在网页上呈现表单。这些注释放在模型或实体类中。您通常会直接使用实体类，因此如果您在此处添加注释，它可以消除相当多的开销和重复工作。由于您的注释直接放在模型类上，因此您无法获得生日信息的视图，这是不可能的。此外，通过遵循模式，您可以去除不会为最终结果添加值的垃圾。您只需编写业务逻辑，而不是其他任何内容。

虽然注释与模型层在同一个类中，但是表示层或视图层由注释和帮助程序类组成。它不一定是不同的类或边界。

另一个例子是。我过去曾经在一些PHP网络“应用程序”上工作过。我使用应用程序是因为它们是一个单片代码块，或多或少是一个主要方法，其中包含所有逻辑（这几乎不是一个功能应用程序）。

如果不将代码抽象为函数并只使用单一方法，那么最终会产生大量的重复工作。如果你试图理解那个单片代码块，你会遇到一堆麻烦（就像我一样，很难知道发生了什么，然后我会在其他地方找到一个类似的代码块，并且傻眼了为什么一个很少有事情按照他们的方式进行调整。）

它可以以您想要的任何方式完成，但是MVC等设计模式可以帮助您简化您所编写的内容，以使其工作，并且更轻松地围绕解决方案。另一种流行的设计模式或方法是分而治之。

回答您的原始问题：

在Java中，本地化数据将由应用程序透明地完成。例如，如果您需要美国英语语言环境支持，则需要创建属性文件：

<强> messages_en-US.properties

然后将所有美国英语内容放在那里。根据可能的内容大小，您可能希望使用不同的方法。

对于我的应用程序，我有不同语言的整页，所以我所做的就是这个。我的控制器确定客户端的区域设置或最佳匹配。然后它选择要显示的视图并将模型（数据）传递给视图。

如果您需要动态格式化日期/时间，那么您的控制器负责确定将使用哪一个。然后，您的视图负责使用该转换器格式化值。

我正在使用JBoss Seam，因此仍然使用MVC设计模式，但更抽象。我没有实际的'控制器'，而是一个拦截器负责处理特定的功能（确定客户端的区域设置，然后是另一个用于其日期/时间偏好）。我的控制器相当于一个Spring Controller，它是负责处理页面操作的动作组件。

沃尔特

Answer 3

所有这些东西看起来像表示层逻辑，所以我个人认为它应该在视图中。

ETA：

我不主张在一般意义上让视图调用服务层对象，但对于本地化，我认为这是有道理的。

例如，假设您在页面上有许多静态文本，这些文本已经被标记化并以各种本地化形式存储在数据库中。我不认为控制器必须在模型中查找并放置所有这些文本标记是有意义的。即使文本标记查找在技术上是一个“服务层”操作，我仍然认为视图通过某个实用程序类直接调用该服务而不是让控制器执行它是有意义的。

Answer 4

视图负责此而不是控制器。

要解释我需要详细说明“视图”是什么：

在基于Web和传统的GUI MVC模式中， View负责显示模型的任何部分的外部表示。如果这意味着“格式化”模型中的数据，那就这样吧。

控制器不应格式化数据 - 因为控制器负责根据来自外部世界的事件/命令对模型进行操作。控制器与渲染输出无关。

示例：

我想显示一个包含多个订单行的购物车：

• 向购物车添加内容会导致控制器更改购物车型号中的内容。
• 更改我的区域设置会导致控制器更改用户模型中的设置以指示首选区域设置。
• 每当显示购物车时，视图都必须向模型询问订单行并决定如何显示 - 可能是对区域设置敏感的工作。
• 同一位客户可以要求以多种不同货币查看购物车。这只意味着改变视图中的样子。对于同一个客户来说，它仍然是相同的购物车。
• 如果这是一个由网页模板页面制作的网络应用程序，您可以嵌入代码以引入本地化消息，例如<%= message_renderer.text(:insufficient_funds) %>。在这种情况下，“message_renderer”和模板文件都是视图的一部分。

视图不一定只是基于Web的模板。例如，在某些基于Java的框架中，我们将“视图对象”放入速度模板中。这些视图对象链接回模型中的对象，但它们也执行按需呈现和格式化行为。这些都是视图的一部分，尽管它们不仅仅是模板。

对于像rails上的ruby和grails上的groovy这样的框架来说，它有点令人困惑，他们将模板称为“视图” - 当视图真的不仅仅是模板时。传统上（在Smalltalk MVC和Java的Swing中）视图只是可以执行格式化，呈现和任何其他与显示相关的行为的代码。