我应该在哪里放置输出字段描述，控制器或模型？

我注意到我坐在几个控制器的顶部有一段代码。他们往往是这样的：我应该在哪里放置输出字段描述，控制器或模型？

def app_description(app): 
    """ Dictionary describing an app. """ 
    return {'name': app.app, 
      'id': app.id, 
      'is_new': app.is_new(), 
      'created_on': app.created_on.strftime("%m/%d/%Y"), 
      'configured': app.configured }

我就可以在控制器中的几个不同的动作调用此方法，但一般并不控制器之外。它访问属性。它调用方法。它格式化不透明的对象（如日期）。

我的问题是：这是控制器代码，还是型号代码？

为控制器的情况下：

它定义了我的API。
它目前仅在该模块中使用。
这里似乎没有任何逻辑。

为模型的情况下：

这似乎是对数据的描述，模型应该负责。
感觉就像我可能想在其他控制器中使用它。还没有到那里，但这些功能还是很新的，所以他们可能会。
将函数附加到它明确属于的对象似乎比将其作为模块级函数更好。
它可以更简洁地定义在模型上。像顶级模型对象定义为.description()，并且子类仅定义属性的黑/白列表，并且重写方法本身以调用函数。我敢肯定，这将是更少的代码行（因为它会让我省去像'name': app.name这样的重复），这似乎是件好事。

来源

2012-01-13 TR.

真正的问题是'MVC'不适用于web开发那么好.. – plaes 2012-01-13 19:24:35

答案我终于决定：

在短期内，有这些方法是在控制器的罚款。如果他们定义输出，那么，好的，他们可以留在那里。他们只在模型中使用。

即使世界几件事情要注意，这表明他们已经长大了，需要去其他地方：

在一种情况下，我需要访问对象的规范序列化。此时，它作为模型方法进入模型。
在另一个案例中，我发现我将所有时间戳的格式设置为相同。我有一个标准的@ajaxify修饰器，它可以处理集合Content-Type标题，JSON编码等。在这种情况下，我将日期时间标准格式转移到那里 - 当JSON编码器击中日期时间（以前是不可序列化的）时，它总是将其视为相同的时间（对于我来说，自纪元开始秒）。
在第三种情况下，我意识到我在一个控制器中重新使用了这个功能。为此，我将它拖入一个普通的类（如另一个建议的答案），并用它来定义我的“Web API”。之前我使用过这种模式 - 对于类似使用的数据（如时间序列数据或前N个列表）进行分组是有意义的。

我怀疑还有更多，但基本上，我不认为这些都与我最初认为的相似。我目前很高兴将它们视为我们（小型，新型）代码库中的简单对象约定，并且理解经过几次迭代后，可能会出现更好的解决方案。同时，他们留在控制器中并定义我的AJAXy-JSON专用接口。

来源

2012-04-19 19:15:33

不知道你正在使用的框架，但我建议建立在自己的类这个辅助功能，并把它放在像lib中的共享文件夹/

或者你可以有一个应用程序辅助模块，只是有一堆这些有用的应用程序范围的功能。

无论哪种方式，我都会将它远离模型和控制器。

来源

2012-01-14 13:19:02 Flaviu

我不认为把它们从两个地方拉开是有意义的。由于它们只用于那一个模块，所以我决定现在就离开控制器，并且在每次重新访问代码时都要谨慎考虑我正在试图用这个逻辑来做什么。不过谢谢你的想法。 – 2012-04-19 19:17:47

还有一个想法：我们肯定有一些输出格式化代码，它在lib中有自己的模块。一旦这些功能需要在多个控制器中使用，那么拥有一个用于格式化Web API的单独定义的模块是非常有意义的。 – 2012-04-19 19:19:30

我应该在哪里放置输出字段描述，控制器或模型？

回答

相关问题