Design patterns 在多层体系结构中，应在何处转换表示值？

我正在构建一个多语言、多时区和n层的应用程序。所有日期均以UTC格式存储在数据库中，所有模型对象均填充UTC时间。但是，从不显示UTC时间（除非用户碰巧将时区设置为UTC）

这意味着我需要重复地将时间属性转换为正确的用户时区。重复总是坏代码的标志或更好的方式，所以我试图找出最佳的实现策略。虽然这实际上是一种表示逻辑，但我的想法有所不同，因为模型似乎应该知道当前用户的正确值。到目前为止，我的想法是：

使用静态帮助器类，然后在每次使用模型的属性时调用它。这似乎容易出错或被遗忘，并使计算变得繁琐

在viewmodel对象中包裹模型对象。这同样很麻烦，尤其是在处理对象列表时

为仅存在于表示层中的模型编写扩展方法。这看起来更干净，但不直观

在模型层中为转换创建接口。在表示层实现helper，并为模型层提供实现。然后，模型具有使用接口转换时间的属性。这似乎应该打破关注点之间的分离，但似乎没有。如果您有一个默认的转换器，那么您就不必担心得到空对象异常，但是模型层（当前为POCO）将需要一个容器来存放转换助手，这看起来很混乱

在模型上创建“转换为本地时区”方法，并传入当前时区

我对这些策略或任何其他我应该或可能用来代替这些策略的观点感兴趣

更新 我目前所做的是在模型层中创建一个ITimeConvertor和一个ITimeConvertorFactory。然后，我创建了这些的默认实现，它们只返回原始日期值。在模型层中，我为最初位于模型上的每个现有UTC属性添加了localtime属性。在这些属性中，我使用工厂获取一个转换器，并在getter和setter中以每种方式转换UTC值。我不得不在模型层（我不太喜欢）中添加一个静态设置类，作为存储当前时间转换器工厂的位置。在web应用程序部分中，我将ITimeConvertorFactory和ITimeConvertor实现为WebTimeConvertorFactory和WebTimeConvertor。WebTimeConverter了解会话和当前用户，因此可以获取当前时区。WebTimeConvertor工厂创建WebTimeConverter。当应用程序启动时（application_onstart in global.asax），我创建工厂并将其传递给模型层静态设置属性。这使我的模型层能够转换本地时间，而数据层只知道UTC日期属性。这也意味着我可以将localtimes直接传递到模型中，并在消费应用程序提供转换器工厂的情况下对其进行精确转换。由于UTC属性保持不变，它们仍然可以在应用程序中的任何位置使用。 虽然它看起来像是很多代码，但我发现这个解决方案在实现后非常干净，因为它允许服务的其他使用者以他们想要的方式实现他们的时间转换（如果有的话），同时也保持模型属性的消耗合理明显

---

我仍然对更好的解决方案持开放态度，并对我当前的解决方案提出批评。

我假设是您的模型层知道用户的时区，因此转换时间属性取决于模型层。否则，您必须让表示层知道时区，并在那里转换每个时间值

在模型层中转换时间值将允许在表示层中使用它们，而无需任何转换，因此我认为这将是干净的。例如，您可以在开始时使用转换的时间初始化对象（POCO）。但是要小心在模型中重新转换它们，忘记它们已经初始化为本地时间。此外，如果用户可以编辑时间值，则需要在保存之前将其转换回UTC时间

更新： 经过进一步思考，我认为UTC时间是模型的一部分，localtimes是该模型的一个视图，因此转换职责更多地属于表示层（以我不同意为代价）。使用相同的思维过程，将localtime属性与UTC时间一起使用本质上是重复的，转换仍然在模型层中。为了克服这个问题，用户POCO中可能有一个只读的

UTCToLocalTimeConverter

-type属性，该属性用时区初始化（这也消除了对静态方法的需要）。然后，页面中对时间属性的所有调用都将封装在转换器的

ConvertToLocalTime

方法中，该方法可通过用户访问。如果愿意，也可以将转换器实例直接放在

会话中

我不知道这种方法是否适用于您，但它是受您的策略启发而来的，我认为设计的其余部分以这种方式运行更为顺畅。此外，到localtimes的转换仍由客户自行决定。缺点是必须转换客户端中的所有时间值，但在我看来，这是摆脱数据重复和静态方法的必要条件。
我想这是我的观点之一，我的模型层是否应该知道用户所在的时区？目前没有。我的内部争论是这是演示还是模型层决策。用户POCO存储时区，但用户POCO存储时区