模型逻辑中的 Django 模板答案

【问题标题】：django templates in model logic模型逻辑中的 Django 模板
【发布时间】：2012-02-27 09:44:04
【问题描述】：

我希望生成与有限 (>20,

class Message(models.Model):
    MSG_CHOICES = (
        ('MEETING', 'Meeting Reminder'),
        ('STATUS', 'Status Change Reminder'),
        ...
        )
    message = models.CharField(max_length=100)
    msg_type = models.CharField(max_length=10, choices=MSG_CHOICES)

每个的实际消息将取决于我必须在某些时候提供它的类型和参数。例如，“MEETING”消息基本上是：

"Hi, you have a meeting at %s with %s." % (time, person_to_meet)

虽然“状态”消息类似于

"Hi, this is a reminder that you changed your %s status to %s." % (status_type, new_status)

现在，这里的复杂性在于我们必须针对不同的类型以不同的方式呈现消息。以下是我尝试集思广益的一些不同方法：

修改模型，使每个模型都有一个基本消息模型和一个派生模型，每个模型都有自己的构造函数类型，在每个模型的构造函数中保存“字符串模板”。这符合用不同逻辑分离模型的模式（我通常会为不同“类型”的模型这样做），但感觉很笨拙，因为除了创建消息的逻辑之外，这些人基本相同。逻辑上的唯一区别在于消息本身的创建，仅仅因为它而拆分似乎是一种浪费。
保持模型不变，在代码中创建类方法为每种类型创建一个工厂，将“字符串模板”保存在类中（甚至在数据库中）。这是最简单的，但感觉很脏。
这是创意/疯狂的一个（因此得名）：保持模型原样，并将字符串模板保存为实际模板文件。在构造函数中，使用 Django 模板库来呈现这些文件并返回字符串。这看起来不错，因为它将硬编码数据与代码逻辑分开，但感觉很不稳定，因为我在代码的两个不同级别（一个用于制作模型，一个用于视图）上使用模板。它“感觉”不对，但我无法确定原因。

所以主要问题：

这种情况的最佳做法是什么？是其中一种还是其他方法？
在某处是否有这种做法的“模型”示例？我觉得很多系统都会生成自动警报/消息，所以如果有一个特别好的代码，我想看看它。

谢谢！

-颜

【问题讨论】：

查看您的消息样本似乎 post_save 方法可能是提高它的好点。你觉得怎么样？。我的应用程序也提出了消息，而且我不知道在哪里提出它的最佳点，在视图或 post_save 上。我关注你的问题。
好吧，如果问题只是在视图或 post_save 上执行，我觉得 post_save 绝对比视图好，因为人类可读消息与用于生成消息的数据的关联是模型级逻辑，不应依赖于视图。你怎么看？
我正在等待回答您问题的人。在我看来：我第一次在 post_save 中编写了这个规则，但是很难检查消息应该提出的条件，然后我转向视图。此时我要回到 post_save。我总是不喜欢在模型上编写代码和业务规则。

标签： django-models django-templates

【解决方案1】：

恕我直言，您根本不应该将消息存储在数据库中。您正在存储 msg_type。那应该真的足够了。您向用户显示信息的逻辑（通过模板）应该处理这个问题。如果您需要在将来的某个时候基于 Accept-Language 标头本地化消息，这将允许您本地化消息。以我的经验，将用户消息存储在数据库中是一个坏主意。而且，至少在我看来，这并不是真正的商业逻辑。它似乎属于UI层。好的。只是我对此的看法。这个问题很老了。我很想知道你最终在这里做了什么。

【讨论】：