一个具有多个型号的应用程序与具有单一型号的多个应用程序

Question

我目前正在用Django开发我自己的博客。但我在一开始就已经做好了准备。所以，下面是我的树形层次结构：

/pyroot/nemoden/
|~blog/
| |-__init__.py
| |-admin.py
| |-models.py
| |-tests.py
| `-views.py
|+css/
|+images/
|+js/
|~templates/
| |-index.html
| `-postslist.html
|-__init__.py
|-manage.py
|-settings.py
`-urls.py

我所做的是:创建了一个名为blog的新应用程序，并描述了我在blog/models.py中创建博客所需的所有模型(用户、帖子、评论等)，但后来我看了Jeff Hui's video，意识到这可能是一个坏主意，在Django-world中人们不会这样做……我们在做什么.使用我们的PHP Frameworks的PHP-world。我想最好是为标签、评论、用户等提供与众不同的Django应用程序……

所以，我想问的是：

每个Django-app有一个模型是不是更好？如果是这样，当我不应该为模型创建新的Django-app时，是否有一些例外？

我想说：

/pyroot/nemoden/
|~blog/ # this is actual application (not a django-application). It uses all the models in views.py, so django-apps becomes just models
| |-__init__.py
| |-tests.py
| `-views.py # all the views (controllers in other frameworks) used by our (well,... my) weblog
|+css/
|+images/
|+js/
|~templates/
| |-index.html
| `-postslist.html
|-__init__.py
|~post/
| |-__init__.py
| |-tests.py
| |-admin.py
| |-models.py # only Post model goes here
| `-views.py
|~tag/
| |-__init__.py
| |-tests.py
| |-admin.py
| |-tag.py # only Tag model goes here
| `-views.py # <---- I don't know why we still need it here!
|-manage.py
|-settings.py
`-urls.py

正如你所看到的，我从blog应用程序中去掉了models.py和admin.py，所以现在的blog应用程序更像the app或main app，它使用了所有的模型(django-apps)，主要由views.py组成。我认为现在我们不需要在所有的django-apps中都使用views.py (尽管这一点有一个很大的问号--它只是理论上的)。

我的方法有没有好处，或者我现在可能会遇到一些看不见的问题？

Answer 1

是不是每个Django-app都有一个模型更好？

可重用应用程序的关键思想之一是:做一件事，并把它做好

如果一个应用程序需要多个模型(PostEntry，如果是博客应用程序，则为PostAuthor )，这绝对不是坏事。然而，标签、类别、评论代表了不同的功能，理想情况下，这些功能可以在另一个上下文中重用，因此应该作为独立应用程序分发。

有没有最佳实践？

为了对一个好的应用程序组织有一个感觉，我首先看一下Django Reusable App Conventions。

然后您就准备好听James Bennett关于DjangoCon 2008 (Slides)中的Resuable Apps的演讲了。关于同一主题的另一个较新的观点是来自PyCon 2011的Pluggable Django Application Patterns

Answer 2

经验法则是，一个“应用”应该是一个完整的功能。如果你的博客不能在没有标签的情况下运行(就像字面上说的那样，有标签的博客比没有标签的博客更好)，那么标签应该是博客应用程序的一部分。

然而，这里没有明确的答案。一些应用程序纯化者完全专注于可重用性，并使每个应用程序成为独立的功能块，几乎不依赖于其他任何东西。有些人使用单个Django应用程序创建整个应用程序。在你的特定场景中，什么才是最有意义的，这真的由你自己决定。

一般来说，我会说将其他应用程序不太可能使用的功能组合在一起，但这个应用程序需要这些功能，所有这些功能都在同一个应用程序中。像标签或评论这样的东西可能是他们自己的应用程序的候选者，事实上，你可以找到许多这样的应用程序，可以简单地插入到你的应用程序中来提供这些功能。

在任何比简单的待办事项列表更复杂的应用程序中，你几乎不可避免地会以大量的交叉而告终。没有一个正确的答案。只要使用常识，干净利落地思考(不要重复自己)，你就会做得很好。

Answer 3

我在youtube上找到了一个家伙，上面说他解决了这个问题:既有一个巨大的应用程序，也有很多他认为不好的小应用程序。

http://youtu.be/URztqq1kiqI?t=22m39s

根据我自己的经验:你不会想要一个大的应用程序，因为人们可以处理更好的文件夹树，这些文件夹树分散得很少，但不会太多。另外，只有一个应用程序会让你更难掌握项目的组成部分(对于新人来说)

另一方面，你拥有的应用程序越多(它们确实是相互依赖的)，你遇到循环导入问题的可能性就越大。所以你需要一个策略来避免这些事情。在这里，新成员往往会将项目带入问题。

总而言之，在更多项目上开发过更长时间的人通常应该是架构决策的制定者。