什么是app

app是django项目的基本组织单元,其本身是标准的python package,只是其中还会有符合django约定的py文件,如models.py等。

如何划分app

从网上看到的各种说法来看,划分app的建议是功能逻辑的“内聚性”。将独立的具体功能放置在一个app中,于是app既划分了功能需求也是在多个django项目之间进行代码重用的手段。

一个简要的指标是,当models.py中的model超过5个(10个)后就可以考虑拆分了。

那问题呢

app划分困难

  • 首先,项目中很难有一个彻底独立的模块,功能需求间总会有相关联的内容。这个时候分或是不分就成了问题。
  • 其次,随着项目的进行需求变化功能增加是少不了的。也许开始时app划分的很不错,但随着代码不断被添加,app逻辑上的内聚就会出现些问题,总会混杂进新代码。

app拆分困难

  • python代码重构ide支持较差,动态语言的硬伤。没有ide帮助下进行重构是相当有风险的,且这么吃力不讨好的事情最好避免去做。

数据库同步易出问题

  • syncdb/south并不一定能在此种场景下正常工作,随便出点什么问题就够头疼了。

不用app行不行

当然可以,将所有逻辑放到一个app中就可以了。这里还是想吐槽下django关于models.py、views.py、tests.py的约定,

单一文件真能满足大项目的需求吗?

将多个model放在一个models.py中很容易就会让这代码膨胀,这里还是更偏好java的形式,一个class一个类,简单明了。

有什么好处

  • 数据库同步简便。south schemamigration/migrate只需要操作一个app即可,容易保证一致性。
  • 层次依然清晰。在一个app中同样可以将代码逻辑整理清楚,python package就已经可以进行层次化设计。

有什么坏处

  • 不django,要是放到github上去没准就会被bs..

结论

个人结论就是通过package组织代码,避免创建使用多个app,减少数据库同步问题。如若代码需要进行项目间的重用,可以随时提前模块化的package。

以上观点来自于目前的项目经验,也许之后会认为app才是正道也不一定。