python - 如何设置3层Web应用程序项目

Question

编辑：

我添加了[MVC]和[design-patterns]标签来扩大此问题的受众范围，因为它更像是通用编程问题，而不是与Python或SQLalchemy无关的事情。它适用于具有业务逻辑和ORM的所有应用程序。
基本的问题是将业务逻辑保存在单独的模块中，或者将其添加到我们的ORM提供的类中是否更好：

我们有一个flask / sqlalchemy项目，我们必须为其设置一个要工作的结构。关于如何进行设置有两种有效的意见，并且在该项目真正开始之前，我们要下定决心。他们。
如果你们中的任何一个可以给我们一些见解，那就是两者中的哪个更有意义以及为什么，以及优点/缺点将是什么，将不胜感激。



我的示例是一个HTML字母，该字母需要批量发送和/或显示给单个用户。这封信可以包含显示发票和/或物品清单的部分，以供收件人选择。



方法1：
将代码分为3层-第一层：Web界面，第二层：字母处理，第三层：ORM（sqlalchemy）中的模型。
该网站将在第二层的类中调用服务器端方法，第二层将遍历需要获取此字母的用户，并且它将具有内部方法，这些方法生成HTML并替换该字母中的某些通用字段，当前用户的信息。它还具有内部方法来生成发票或要放入信函中的物品清单。

在这种方法中，第三层仅用于从数据库以及与数据库相关的某些逻辑（例如，根据用户的名字和姓氏生成全名）来获取数据。第二层完成大部分工作。

方法2：
将代码分成相同的三个层，但仅在第二层的用户集合中执行循环。

生成HTML，发票和商品清单的方法都作为方法添加到ORM提供的第3层模型定义中。第2层执行循环，但实际功能包含在第3层的模型类中。

我们得出的结论是，这两种方法都可以使用，并且各有利弊：

方法1：


将业务逻辑与数据库访问完全分开
防止导入ORM模型还会导入我们可能不需要的许多方法/功能，也使模型类的代码更加紧凑。
模拟出ORM模型进行测试时，可能会更易于使用


方法2：


似乎与Django在Python中执行操作的方式保持一致
允许简单地访问方法：当存在模型实例时，它具有任何功能
表演可以立即被调用。 （在我的示例中：当我有一个字母实例时，我可以直接在其上调用为该字母生成HTML的方法）
您可以使用所有合适的方法来传递实例。

Answer 1

通常，您将MVC模式用于此类操作，但是python中的大多数Web框架都删除了“ Controller”部分，因为他们认为这是不必要的组件。在我的发展中，我已经意识到这是真的：我可以没有它而生活。这将使您剩下两层：视图和模型。

问题是现在将业务逻辑放在何处。从实践意义上讲，有两种方法可以执行此操作，至少我可以通过两种方法将逻辑放在哪里：


创建特殊的内部视图方法来处理逻辑，这可能在多个视图中都需要，例如_process_list_data
创建与模型相关但未直接绑定到相应模型模块内单个实例的函数，例如check_login。


详细说明：我将第一个用于严格与显示相关的方法，即它们某种程度上与处理用于显示目的的数据有关。在我上面的示例中，_process_list_data位于视图类（按用途对方法进行分组）中，但也可以是模块中的普通函数。它接收一些参数，例如数据列表并以某种方式对其进行格式化（例如，它可能会添加其他视图参数，从而使模板的逻辑更少）。然后，它将数据集返回到原始视图函数，该函数既可以传递它，也可以对其进行进一步处理。

第二个用于其他大多数逻辑，我喜欢将它们保留在直接查看的代码之外，以便于测试。我的check_login示例这样做：它不直接与显示输出绑定，因为它的目的是检查用户登录凭据并决定返回用户或报告登录失败（通过引发异常，返回False或返回None）。但是，此功能也没有直接绑定到模型，因此它也不能存在于ORM类中（对于staticmethod对象，它可能是User）。相反，它只是模块内部的一个函数（请记住，这是Python，您应该使用最简单的方法，并且函数已经存在了）

总结一下：在视图中显示逻辑，在模型中显示所有其他内容，因为大多数逻辑都以某种方式绑定到特定模型。如果不是，则仅为此类逻辑创建一个新的模块或软件包。这可能是一个单独的模块，甚至是一个包装。例如，我经常为辅助函数创建一个util模块/程序包，这些函数不直接绑定到任何视图，模型或其他对象，例如，用于格式化日期的函数，该函数从模板中调用但包含太多的python，在模板中定义会很丑陋。

现在，我们将这种逻辑带入您的任务：处理/创建信件。由于我不确切知道需要执行什么处理，因此只能基于我的假设给出一般性建议。

假设您有一些数据，并且想把它写成一封信。例如，您有一个articles列表和一个购买这些文章的costumer。在这种情况下，您已经有数据。在将其传递给模板之前，唯一需要做的就是重新格式化它，以使模板可以轻松使用它。例如，可能期望例如通过数量，价格或物品编号来订购购买的物品。这是与模型无关的，现在订单仅与显示相关（您可以在数据库查询中已经指定了订单，但是假设您没有）。在这种情况下，这是视图执行的操作，因此您的模板已准备好将数据格式化以显示。

现在，假设您要获取数据以创建特定字母，例如，用户随时间流逝的商品清单，购买日期和其他详细信息。这将是模型的工作，例如创建一个查询，获取数据并确保它具有此特定任务所需的所有属性。

假设在这两种情况下，您都要检索产品的价格，并且该价格由基本值和基于其他属性的一些百分比确定：这对于模型方法是有意义的，因为它对单个产品或订单实例进行操作。然后，您将模型传递给模板，并在其中调用price方法。但是您也可以通过以下方式重新设置格式：在视图中已经进行了调用，并且模板仅获取元组或字典。这样可以更轻松地将相同的数据传递给API（请参见下文），但不一定是最简单/最佳的方法。

做出此决定的一个很好的规则是问自己：是否要在标准视图之外另外提供JSON API，我将如何修改我的代码以使其尽可能地干燥？如果刚开始时理论上还不够，请为模板构建一些API，然后在视图本身旁边查看需要更改API的地方。您可能永远不会使用此API，因此它不一定是完美的，但是它可以帮助您弄清楚如何构造代码。但是，正如您在上面看到的，这并不一定意味着您应该以仅返回可以转换为JSON的内容的方式对数据进行预处理，而是可能需要为API进行一些JSON特定格式设置视图。

因此，我的工作时间比我预期的要长一些，但是我想向您提供一些示例，因为这是我刚开始并通过反复试验发现这些问题时所错过的。