Django双前台项目中共享Customer模型的位置及架构疑问

Hey there! As someone with 5 years of PHP enterprise framework experience diving into Django, I totally get where you're coming from—let's work through this step by step.

一、共用Customer模型的正确放置方式 #

Django确实不会自动扫描项目根目录（website）下的models.py，因为它只识别已添加到INSTALLED_APPS中的应用里的模型文件。这里有个最规范且易维护的解决方案：

创建一个共享核心应用 #

• 执行命令创建专门存放共享代码的应用，比如命名为core或common：

  python manage.py startapp core
  

• 将你的Customer模型移动到core/models.py中，编写好模型代码（比如字段、方法等）。
• 在项目根目录的settings.py里，把core添加到INSTALLED_APPS列表中：

  INSTALLED_APPS = [
      # 其他默认应用...
      'core',
      'front1',
      'front2',
  ]
  

• 之后执行迁移命令，Django就会识别并创建这个模型对应的数据库表：

  python manage.py makemigrations
  python manage.py migrate
  

• 在front1和front2的视图、模板或其他代码中，就可以直接导入这个模型了：

  from core.models import Customer
  

这种方式和你在PHP企业框架中抽离公共模块的思路一致，能让代码结构更清晰，也方便后续添加更多共享模型或工具类。

二、双应用架构的合理性分析 #

是否合理取决于你的两个前台的业务差异：

• 如果两个前台是独立的业务单元（比如一个是面向普通用户的商城前台，一个是面向商家的管理前台，或者完全不同的业务线），那么拆分成front1和front2两个应用是非常合理的。这种划分能让代码隔离，各自的路由、视图、模板都独立维护，避免耦合。
• 如果两个前台只是UI风格不同，核心业务逻辑高度重叠（比如一个是移动端适配的前台，一个是PC端前台），那拆分两个应用可能会增加冗余代码和维护成本。这种情况下更推荐在同一个应用内，通过不同的视图函数、模板文件或者路由前缀来区分两个前台，共享大部分业务逻辑。

结合你的PHP经验来看，就像PHP框架中如果两个模块业务差异大就拆分成不同的模块，差异小就共用核心代码一样，Django的应用划分也是遵循这个逻辑的。

内容的提问来源于stack exchange，提问作者Ahima