Django中的Python模块

Question

我正在构建我的第一个Django web应用程序，并且需要关于代码布局的一些建议。

我需要将它与其他几个通过RESTful API和Django内部数据公开的其他应用程序进行集成。我需要开发一个组件，它将从各种来源提取数据，django的数据库，将其格式化为输出格式并将其返回以供模板呈现。

我正在考虑写这个组件的最好方法。有几种方法可以继续，我想征求更多有经验的Web开发人员对我可能错过的东西的一些反馈。

路＃1

开发一个完全独立的对象为通过其API等与其他应用程序进行交互。这不会有Django和测试独立相关事情。然后在django中，将模块导入到需要它的视图中，运行对象方法以获得所需的数据等。

如果我需要通过GET请求访问任何此功能（如通过JavaScript），我可以拥有一个导入模块并返回json的专用视图。

路＃2

完全开发本作的Django视图（S）公开为一系列的GET/POST调用，都会打电话给对方，以完成工作。这将直接绑定在应用程序中。

路＃3

开始与路＃，但1，而不是创建视图，它包作为django的应用程式。开发应用程序以及单个对象的单元测试。

我认为这种方式1或3将非常封装和控制。

方式2会更复杂，但是便于更高的组件重用。

从性能的角度来看哪个更好？如果我以方式1或方式3进行滚动，是否会为每个请求实例化对象的实例？

如果是这样，这种方法可能有点太重。如果我继续这样做，他们可以单身吗？

无论如何，我希望这是有道理的。

在此先感谢。

Answer 1

肯定会去“方式＃1”。为您的服务API保留一个独立的层将在以后需要增强该层的可靠性或扩展API时提供帮助。

远离单身人士，他们只是具有新名字的全局变量。为您的界面对象使用适当的生命周期。显而易见的“为每个请求实例化”并不是最糟糕的想法，如果需要（通过缓存和/或记忆）进行优化比在全球范围内展开全局变量更容易。

请记住，Web应用程序应该是一个“无共享”设计的几个进程;唯一的共享资源必须在应用程序外部：数据库，队列管理器，缓存存储。

最后，尽量避免直接从视图函数/ CBV中使用此API。可以从模型中使用它们，也可以在概念上编写一个与从视图中使用模型相似的图层。不需要类似ORM的api，而是将任何“业务流程”保留在视图之外，这些视图应该只涉及演示和高级操作。把你的API作为一种新的模型来思考“粗模型，精简视图”。