问Django的管理面板只是临时的脚手架吗？

EN

我不会说管理员是临时的脚手架，但它可能不是许多情况下的最佳选择。我曾与一家非常大和知名的媒体公司合作，该公司使用管理员作为其制片人和编辑的整个工作流程界面的基础。不幸的是，您关于何时或何时不使用admin的决策过程将在很大程度上得益于您对Django内部结构的全面了解；在获得了解何时不会卡住的经验之前，您可能会被卡住几次。:p

管理员的“可定制性”可能有些主观。我见过团队屈从于自己的意愿，但这也需要相当好的底层工作知识-模型、表单(自然也包括ModelForms和FormSets)和模板的细节。我认为许多传统的智慧和最佳实践还没有出现在有组织的文档中。准备好在源代码中做大量的挖掘。好消息是，您可能会对如何利用框架中的一些一流实体有更深入的理解。坏消息是，你的老板可能不会高兴，因为你花了一天的时间来改变表单上的单一输入。

最近的增强使得将您自己的视图放在admin URL空间下变得更容易，因此您可以考虑一种方法，即编写您自己的视图以满足您的需要，并在标准管理页面的适当位置添加链接。我通常建议刚接触Django的人或刚进入管理定制的人强烈考虑只滚动自己的管理视图。毕竟，Django已经让创建CRUD风格的应用变得非常容易，而且每当你想要改变表示或行为时，你都不会觉得自己在与一个僵化的系统作斗争。

Django Admin适用于除了它提供的默认添加/更改/删除处理之外没有任何价值的事情。

数据库中充满了查找和管理表。例如，任何最终用户都不应该看到的邮政编码到州的映射。后台批处理作业执行的日志。

您的应用程序可能会有一些表，这些表或多或少是“管理”的--有人维护它们，而不是庞大的用户社区。

您的应用程序可能会有一些供最终用户添加/更改/删除的表。您可能希望为此活动提供大量的自定义页面。

姜戈从小就在新闻业长大。编写者和编辑者准备数据(使用管理界面)。客户通过定制的网页读取数据。

我们有使用管理页面的管理人员。我们为我们的客户定制了页面。我们两者都使用。

我们提供的默认管理页面上的几乎一切，我们的内部管理员。我们为客户端管理员提供对所选表的默认管理。我们还为客户提供精心设计的特定于应用程序的页面。

大约6个月前，当我刚开始在Django工作时，我问了一个类似的问题。

Is it worth it using the built-in Django admin for a decent sized project?

对于那个特定的应用程序，我选择不使用Django admin，事后看来这是一个非常明智的决定。从那时起，我通常不再使用它，但有时也会出现它很棒的情况。对我来说，这真的取决于用户。如果我们正在为客户端构建一个自定义的数据驱动应用程序，并且正在使用他们提供的功能集，那么我永远不会想要使用Django admin。在这些情况下，几乎可以肯定的是，他们会有一些变化，这可能是一个真正的痛苦，试图在管理员中工作。如果它是一个不断发展的项目，这些变化将变得越来越像黑客，你最终可能不得不开始将部分内容拆分到站点的非Django管理部分，在这一点上，现在有两个界面来做事情。

但是，如果客户更倾向于接受应用程序的工作方式，那么Django管理员将会很好，假设您的表和他们正在处理的数据之间通常存在1:1的对应关系。

正如Brian Luft所说，为CRUD应用程序创建接口真的很容易，所以如果你觉得将来需要任何定制，最简单的方法可能就是从一开始就编写自己的界面。作为超级用户，您可以随时保留django管理员以满足自己的需要。这就是我通常要做的，所以我可以很容易地拥有表级访问权限来更改那些在普通用户管理员中可能不会显示的字段。