大型Django项目的前端结构

Question

几天前，我开始在新公司工作。在我之前，所有的前端和后端代码都是由一个人编写的。

如您所知，Django应用程序包含两个用于前端的主目录: /static -用于静态(公共)文件，/templates -用于django模板。

现在，我们有超过10个不同的模块，如:家庭，管理，spanel，移动等大型应用。

这是当前文件和目录的结构：

第一个- /static目录。如您所见，它是混合目录，其中一些命名为类似模块，有些包含全局库。

再来一次：

第二- /templates目录。有些目录名为模块，具有混合模板，有些目录依赖于新版本=)，有些目录仅在模块中使用，但在全局放置。

还有更多：

我认为，这是丑陋的，不可维护的，放应力结构！

经过一段时间的时间，我建议使用该方案，即基于模块结构.

首先，我们有版本目录，用于保存完整的项目备份，包括: /DEPRECATED目录-用于旧的、未使用的文件和/CURRENT (活动)目录，其中包含

项目的生产版本。

我认为这是正确的，因为我们可以快速和容易地访问旧的或更新的版本文件。另外，我们可以避免不同版本之间的依赖关系中断或错误。

第二，在每个版本中我们都有独立的模块和全局模块。

每个模块都包含自己的/static和/templates目录。这种结构用于避免不同模块之间的中断或错误依赖，因为每个模块都有自己的js应用程序、css表和本地映像。

全局模块包含所有库、主样式表和图像，如徽标或图标.

我认为，这种结构更适合于维护、更新、重构等。

我的问题是：

你怎么看，这个计划比现在好吗？这个方案能继续使用吗，还是无法在Django应用程序中实现？

Answer 1

所谓“模块”，是指应用程序吗？Django已经有了一个相当标准的结构来放置文件。

我建议你考虑使用这种结构。首先，几乎所有你会得到的帮助都有这个结构的例子。

至于你的结构，在我看来，它看上去很杂乱。不过，这取决于你。特别是，如果它适合业务问题，您将不会遇到导航问题。

Answer 2

在我看来丑陋的观点：

1. 为什么不是版本控制系统呢？将版本保存在本地文件系统上是不太好的。您也可以使用版本控制系统并添加第三方javascript/css库，因此添加/删除/替换javascript和css文件将是可跟踪的。您可以在修订之间往返，轻松地检查差异。
2. 开发一个模块需要同一第三方软件的不同版本的软件是很困难的。如果您的admin模块需要jQuery X，而Products模块需要jQuery Y，那么您就有问题了。它很难维护，只有您才知道为什么每个模块都需要特定版本的jQuery X，为什么不能在jQuery Y下运行。由于您在本地驱动器上有每个部署的完整副本，您可能不记得为什么A module需要一个特定的引导版本。对于特定于单个模块的不同js/css文件，您可以在每个应用程序下创建静态目录，并在这里放置特定于应用程序的文件。把这篇文章当作参考
3. Django有一个计划良好的模板结构。您可以对静态文件执行相同的操作。您可能在每个应用程序下都有templates目录，这里有专门针对palce应用程序的模板。
4. 拥有特定于应用程序的templates和static目录取决于开发人员。如果在同一个目录下的所有文件看起来都很难看，那么您可以选择特定于应用程序的解决方案。姜戈会很好地处理好他们俩。特别是如果您有很多应用程序，那么如果您的所有模板和静态文件都位于同一个目录下，则可能会出现名称合谋。

现在的形式比旧的要好得多。但是我相信，如果您检查Django文档并检查SO/程序员类似的情况和解决方案，您可能会得到更好的想法。

Answer 3

我认为这是一个很好的结构，但我建议您不要使用django模板或任何服务器端模板技术。假设将来您决定(或者不是您，您的老板)在python/django (ruby/rails、symphony2、J2EE、.NET)以外的其他服务器技术中实现某些服务，这样您的客户端html模板就无法使用。我认为使用客户端模板(如mustache.js和其他模板)是个好主意。

查看本文："https://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more“