大型 Django 应用程序布局
我所在的团队正在开发一个基于 Web 的大学门户网站，该门户网站将基于 Django。我们仍处于探索阶段，我正在努力寻找布置项目/开发环境的最佳方式。
我最初的想法是将系统开发为 Django“应用程序”，其中包含子应用程序来分隔系统的不同部分。我打算制作这些“子”应用程序的原因是它们在父应用程序之外没有任何用途，因此单独分发它们没有什么意义。我们设想该门户将安装在多个位置（例如不同的大学），因此可以将主应用程序放入多个 Django 项目中进行安装。因此，我们为每个位置的项目都有一个不同的存储库，它实际上只是一个定义已安装门户应用程序的 settings.py 文件，以及一个将 URL 路由到它的 urls.py 文件。
不过，我已经开始编写一些初始代码，但遇到了一个问题。一些处理用户身份验证和配置文件的代码似乎无家可归。从概念上讲，它不属于门户应用程序，因为它与门户的功能无关。但是，它也无法进入项目存储库 - 因为我将在每个位置的存储库上复制代码。例如，如果我随后发现此代码中的错误，我将必须手动将修复复制到该位置的所有项目文件上。
我的修复想法是使所有项目存储库成为“主”位置项目的分支，以便我可以从该主项目中提取任何更改。我认为这很混乱，这意味着我还有一个存储库需要照顾。
我正在寻找更好的方法来实现这个项目。任何人都可以推荐一个解决方案或类似的示例我可以看一下吗？问题似乎是我正在开发一个 Django 项目，而不仅仅是一个 Django 应用程序。
I am in a team developing a web-based university portal, which will be based on Django. We are still in the exploratory stages, and I am trying to find the best way to lay the project/development environment out.
My initial idea is to develop the system as a Django "app", which contains sub-applications to separate out the different parts of the system. The reason I intended to make these "sub" applications is that they would not have any use outside the parent application whatsoever, so there would be little point in distributing them separately. We envisage that the portal will be installed in multiple locations (at different universities, for example) so the main app can be dropped into a number of Django projects to install it. We therefore have a different repository for each location's project, which is really just a settings.py file defining the installed portal applications, and a urls.py routing the urls to it.
I have started to write some initial code, though, and I've come up against a problem. Some of the code that handles user authentication and profiles seems to be without a home. It doesn't conceptually belong in the portal application as it doesn't relate to the portal's functionality. It also, however, can't go in the project repository - as I would then be duplicating the code over each location's repository. If I then discovered a bug in this code, for example, I would have to manually replicate the fix over all of the location's project files.
My idea for a fix is to make all the project repos a fork of a "master" location project, so that I can pull any changes from that master. I think this is messy though, and it means that I have one more repository to look after.
I'm looking for a better way to achieve this project. Can anyone recommend a solution or a similar example I can take a look at? The problem seems to be that I am developing a Django project rather than just a Django application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我发现解决此问题的最佳方法是创建应用程序，然后创建一个将它们粘合在一起的项目。我的大多数项目都有类似的应用程序，每个项目都包含这些应用程序。电子邮件、笔记、操作提醒、用户身份验证等。我喜欢的布局如下：
apps：
每个“apps”都是独立的，除了
settings.py，不依赖于项目本身（尽管它可以依赖其他应用程序）。其中的应用程序之一是用户身份验证和管理。它在apps/auth/urls.py中拥有完成其任务的所有 URL。它的所有模板都位于apps/auth/templates/auth/中。它的所有功能都是独立的，因此当我需要调整某些内容时，我知道该去哪里。project：
project/包含将这些单独的应用程序组合到最终项目中所需的所有粘合剂。就我而言，我在project/中大量使用了settings.INSTALLED_APPS来辨别应用程序中的哪些视图可供我使用。这样，如果我从INSTALLED_APPS中取出apps.notes，一切仍然可以正常工作，只是没有注释。维护：
这种布局/方法/计划也具有长期的积极影响。您可以稍后重复使用任何应用程序，几乎不需要任何工作。您可以自下而上测试系统，确保每个应用程序在集成到整体之前按预期工作，从而帮助您更快地发现/修复错误。您可以实现新功能，而无需将其推广到应用程序的现有实例（如果它不在
INSTALLED_APPS中，他们就看不到它）。我确信有更好的记录方式来布置项目，并且使用更广泛的方式，但这是迄今为止最适合我的方式。
The best way that I have found to go about this is to create applications and then a project to glue them together. Most of my projects have similar apps which are included in each. Emails, notes, action reminders, user auth, etc. My preferred layout is like so:
apps:
Each of the "apps" stands on its own, and other than a
settings.py, does not rely on the project itself (though it can rely on other apps). One of the apps, is the user authentication and management. It has all of the URLs for accomplishing its tasks inapps/auth/urls.py. All of its templates are inapps/auth/templates/auth/. All of its functionality is self-contained, so that when I need to tweak something, I know where to go.project:
The
project/contains all of the glue required to put these individual apps together into the final project. In my case, I made use heavy ofsettings.INSTALLED_APPSinproject/to discern which views from the apps were available to me. This way, if I takeapps.notesout of myINSTALLED_APPS, everything still works wonderfully, just with no notes.Maintenance:
This layout/methodology/plan also has long-term positive ramifications. You can re-use any of the apps later on, with almost no work. You can test the system from the bottom up, ensuring that each of the apps works as intended before being integrated into the whole, helping you find/fix bugs quicker. You can implement a new feature without rolling it out to existing instances of the application (if it isn't in
INSTALLED_APPS, they can't see it).I'm sure there are better documented ways of laying out a project, and more widely used ways, but this is the one which has worked best for me so far.
您可以将常用功能提取到单独的模块中，并使您的应用程序依赖于它：
我认为“经典”Django 项目似乎“包含” '它使用的应用程序会阻止您看到图片 - 事实上，这是没有必要的。对于一个需要某种可插入模块的项目，我建议将应用程序组织为鸡蛋并使用 zc.buildout+djangorecipe 来管理所有内容。
这样您就可以将模块保持在扁平的单层结构中。 Eggs 具有指定依赖项的能力，因此如果您安装 application1（见上文），auth_module 将自动安装。
此外，将不同的配置部署到不同的服务器也很容易。假设您有安装了 application1 的 server1 和安装了 application1 和 application2 的 server2 - 您可以只有两个配置：
server1.cfg:
server2.cfg:
djangorecipe 还允许您为每个构建配置指定不同的设置文件，这样您就可以将能够将必要的位添加到主项目的 URL 和已安装的应用程序设置中。
更不用说，您还可以有一个单独的配置用于开发配置（例如，安装 debug=True 并安装 Django 调试工具栏）。
You can extract the common functionality into a separate module and make your apps depend on it:
I think the fact that a 'classical' Django project appear to 'contain' the apps it's using prevent you from seeing the picture - in fact, it's not necessary. For a project where you're going to have some sort of pluggable modules I'd suggest organizing the apps as eggs and using zc.buildout+djangorecipe to manage everything.
This way you'll be able to keep your modules in a flat one-level structure. Eggs have the ability to specify dependencies, so if you install application1 (see above), auth_module will be installed automatically.
Also it'll be easy to have different configurations deployed to different servers. Suppose, you have server1 which has application1 installed and server2 which has both application1 and application2 installed - you can just have two configs:
server1.cfg:
server2.cfg:
djangorecipe also allows you to specify different settings files for each buildout config so you'll be able to add the necessary bits to the main project's urls and installed apps settings.
Not to mention, you can also have a separate config for development configuration (with debug=True and Django Debug Toolbar installed, for example).
你应该看看：
我通常使用此项目结构：
/apps 中的每个应用程序都有一个 urls.py，它自动包含在主 urls.py 中。每个应用程序都可以是 git 子模块（或 svn 外部）。
此外，使用 git，您可以在不同的并行分支（master/dev/customerA/customerB ...）上工作并合并更新。
使用 django 创建真正的可重用并不是那么容易。
You should take a look at :
I usually use this project structure :
Each app in /apps have an urls.py thats autoincluded in the main urls.py. And each app can be a git submodule (or svn external)
Also, using git, you can work on different parallels branches (master/dev/customerA/customerB...) and merge updates.
Creating real reusable is not so easy with django.