大型Django应用程序布局 [英] Large Django application layout

问题描述

我正在一个团队开发一个基于网络的大学门户网站，它将以Django为基础。我们还处于探索阶段，我正在努力找到最好的方式来打造项目/开发环境。

我的初衷是开发系统一个Django应用程序，其中包含用于分离系统不同部分的子应用程序。我打算制作这些子应用程序的原因是它们在父应用程序之外不会有任何用途，所以分开分配它们是没有什么意义的。我们预计该门户网站将安装在多个地点（例如，在不同的大学），因此主应用程序可以放置到若干个Django项目中进行安装。因此，我们为每个位置的项目设置了一个不同的存储库，它只是一个 settings.py 文件，用于定义安装的门户应用程序，以及一个 urls.py 将网址路由到它。

虽然我已经开始编写一些初始代码，但我已经提出了一个问题。处理用户认证和配置文件的一些代码似乎没有家庭。它在概念上不属于门户网站应用程序，因为它与门户网站的功能无关。然而，它也不能进入项目存储库 - 因为我将在每个位置的存储库中复制代码。如果我在这段代码中发现了一个错误，例如，我必须手动复制所有位置的项目文件中的修复。

我的修复方案是使所有的项目回收成为主位置项目的一个分支，以便我可以从该主人提取任何更改。我认为这是凌乱的，这意味着我有一个更多的资料库来照顾。

我正在寻找一个更好的方式来实现这个项目。任何人都可以推荐一个解决方案或类似的例子，我可以看一下吗？问题似乎是我正在开发Django 项目，而不仅仅是Django应用程序。

解决方案

我发现最好的办法是创建应用程序，然后将项目粘贴到一起。我的大部分项目都有类似的应用程序，其中包含在每个项目中。电子邮件，笔记，动作提醒，用户认证等。我的首选布局是这样的：

• 项目/
  
  
  
  
  • settings.py
  
  
  • urls.py
  
  
  • views.py
  
  
  • ...
  
  


• apps /
  
  
  
  
  • /
    
    
    
    
    • urls.py
    
    
    • views.py
    
    
    • ...
    
    
  
  
  • notes /
    
    
    
    
    • urls.py
    
    
    • views.py
    
    
    • ...
    
    
  
  
  • ...
  
  

apps：

每个应用程序都是独立的，除了 settings.py 之外，并不依赖项目本身（虽然它可以依靠其他应用程序）。其中一个应用是用户认证和管理。它具有在 apps / auth / urls.py 中完成其任务的所有URL。它的所有模板都在 apps / auth / templates / auth / 中。所有的功能都是独立的，所以当我需要调整某些东西时，我知道要去哪里。

项目： p>

project / 包含将这些单个应用程序放在最终项目中所需的所有胶水。在我的情况下，我在项目/ 中使用了 settings.INSTALLED_APPS ，以辨别应用程序中的哪些视图可用对我来说。这样，如果我从我的 INSTALLED_APPS 中取得 apps.notes ，所有的事情仍然会很好奇，只是没有笔记。

维护：

此布局/方法/计划也有长期积极影响。您可以稍后重新使用任何应用程序，几乎没有任何工作。您可以从下到上测试系统，确保每个应用程序在集成到整个应用程序之前正常工作，帮助您更快地查找/修复错误。您可以实现新功能，而不会将其推送到应用程序的现有实例（如果它不在 INSTALLED_APPS 中，则看不到）。

我相信有更好的文件化方式来布置一个项目，并且使用更广泛的方法，但这是迄今为止对我最好的一个。

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.

解决方案

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:

• project/
  • settings.py
  • urls.py
  • views.py
  • ...
• apps/
  • emails/
    • urls.py
    • views.py
    • ...
  • notes/
    • urls.py
    • views.py
    • ...
  • ...

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 in apps/auth/urls.py. All of its templates are in apps/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 of settings.INSTALLED_APPS in project/ to discern which views from the apps were available to me. This way, if I take apps.notes out of my INSTALLED_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应用程序布局的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！