来自经典ASP，我们正在开发一个相对较大的Django应用程序。我们试图弄清楚如何将此项目的代码分成可管理的部分。
为了论证，我们假设我们有与USERS有多对多关系的CLIENTS，这些用户有一个ROLE，每个角色与RIGHTS有很多对多的关系。
目前，我们在一个应用程序中拥有所有这些，称为“后台”。
缺点是后台应用程序中的forms.py和views.py包含所有这些实体的类。因为应用程序肯定会增长，我们希望将这些实体的代码分成几个文件。 所以，即使它们不是真正独立的应用程序（我认为），它们肯定会处理我们项目后台部分的不同部分。
我已经在互联网上阅读，似乎有两种情绪; One is分割models.py和views.py等，并将它们分成文件夹/模块。在这些文件夹中，我们可以有一个clients.py/users.py/roles.py等。这将保持应用程序完好无损，但是将代码分开。最后，我们会有一个大应用程序，包含大量文件。
The other选项是拆分代码并将客户端，用户和角色转换为单独的应用程序，并删除我们现在完全拥有的“后台”应用程序。 Django鼓励分成更小的应用程序，但这些并不是单独的应用程序，客户端用户和角色密切相关，我们正在创建的维护工具反映了这一点。
我实际上是通过在“后台”应用程序中创建较小的（子）应用程序开始的，但我发现here这是不行的。
问题是，应用程序应该鼓励重复使用，我们正在构建的大型网络应用程序有很多部分交织在一起，并且取决于彼此。没有真正的方法可以将它分成更小的可重复使用的部分，这些部分可以使现实世界更有意义。
所以问题确实存在;在这个例子中，分离用户/客户/角色代码的可行方法是什么，以及这两种方法的优点/缺点是什么？也许甚至有一种我们还没有发现的完全不同的方法......
感谢您的时间。
答案 0 :(得分：1)
始终使用单独的应用。细分models.py等是一个黑客攻击，并且你可以预期黑客攻击。你只需花费大量时间来修理布线。
小型自包含应用程序的主要优势在于可重用性。实际上，您甚至不必将它们作为项目的一部分。事实上，我建议你不要。相反，您可以单独打包每个部分，并像任何其他第三方应用程序一样安装它们，并在INSTALLED_APPS中引用它们。这样，您的项目只关注项目的独特之处，稍后您可以将它们放入其他项目中。这也有强制您编写自包含代码并减少对各个部分和项目的依赖性的附带好处。
auth contrib包中加入了Django。什么还没有，已经作为第三方包装提供，所以你真的只是在这里旋转你的车轮。
答案 1 :(得分：0)
我会考虑将每个人分成自己的应用程序。应用程序结构可能会产生误导。尽管有许多可重用/可插入的django应用程序，但许多项目并未尝试重新打包每个应用程序以供重用。应用程序只是提供了很好的代码分离。
我会想象一个Role有一个模型。可能具有角色特定的实用功能，如果它面向外，则可能具有滚动特定的URL。
这些可能是基本的粗暴行动。
/roles/add，/roles/delete /roles/create，/roles/update/其中每个都可以保证他们自己的应用和urls.py.如果客户端具有相同的操作，那么它们实际上不应位于同一视图中。
这可以在同一个应用程序中使用多个视图解决，但我认为这不适合使用应用程序结构。