一个项目中的多个不同版本的类似应用程序

I need some help to improve the architecture of a site I've built. What I want to achieve within a single Django project is the following:

我需要一些帮助来改进我构建的网站的架构。我想在单个Django项目中实现的目标如下：

• I want a site that comes in several versions (one per year), such that each version has a set of apps that are related to that version.
• 我想要一个有多个版本（每年一个）的网站，这样每个版本都有一组与该版本相关的应用程序。

• I want to keep all the old versions of the site and the state of the apps in that version, but still being able to add/change/remove the apps for any other version. That is, the apps may be different across versions (models, methods, admin, templates, anything basically).

  我希望保留该版本的所有旧版本网站和应用程序状态，但仍然可以为任何其他版本添加/更改/删除应用程序。也就是说，应用程序可能在不同版本（模型，方法，管理，模板，基本上任何东西）上有所不同。

• I want each app that belongs to a version to have the data for that version only. App1 on version 2012 should have one database table, and App1 on version 2013 should have another, even if they are the same.

  我希望属于某个版本的每个应用程序仅包含该版本的数据。版本2012上的App1应该有一个数据库表，而版本2013上的App1应该有另一个，即使它们是相同的。

It could look something like this:

它可能看起来像这样：

site.com/2012
    App1_v1
    App2_v1

site.com/2013
    App1_v1
    App2_v2 (maybe added some fields or methods, changed templates)

site.com/2014
    App1_v2
    App2_v2
    App3_v1

My current solution is rather horrible. When a new version of the site is launched, I simply copy-paste an earlier app and have the old app be as it is, and then adding/modifying the new version of the app. But, as I add more apps and more versions come, I get a stupid amount of apps and it feels like bad design.

我目前的解决方案相当可怕。当一个新版本的网站启动时，我只需复制粘贴一个早期的应用程序，让原有的应用程序保持原样，然后添加/修改新版本的应用程序。但是，当我添加更多应用程序和更多版本时，我会得到一个愚蠢的应用程序，感觉就像糟糕的设计。

How can I achieve this in Django in a better way? Or at least, how can I structure it in a better way? I think about having some base model for each app, from which each version then inherits from, but that still makes a lot of apps.

我怎样才能以更好的方式在Django中实现这一目标？或者至少，我如何以更好的方式构建它？我想为每个应用程序提供一些基础模型，然后每个版本继承，但这仍然会产生很多应用程序。

As an example of an app I have, it may look like this:

作为我的应用程序的示例，它可能看起来像这样：

App name: App_v1_2012

应用名称：App_v1_2012

Model

模型

class Bag(models.Model)
    name = models.CharField()

class Item(models.Model)
    name = models.CharField()
    in_bag = models.ForeignKey(Bag)

View

视图

class IndexView(generic.ListView):
    model = Bag
    template_name = 'sometemplate_2012.html'

App name: App_v1_2013

应用名称：App_v1_2013

Model

模型

class Bag(models.Model)
    name = models.CharField()

class Item(models.Model)
    name = models.CharField()
    in_bag = models.ForeignKey(Bag)

View

视图

class IndexView(generic.ListView):
    model = Bag
    template_name = 'sometemplate_2013.html'

App name: App_v2_2014

应用名称：App_v2_2014

Model

模型

class Bag(models.Model)
    bag_name = models.CharField()
    owner = models.ForeignKey(User)

class Item(models.Model)
    name = models.CharField()
    in_bag = models.ForeignKey(Bag)

View

视图

class IndexView(generic.ListView):
    model = Bag
    template_name = 'sometemplate_2014.html'

As you can see, my biggest problem is the violation of the DRY principle. Everything get copy-pasted, but it's the same information.

如您所见，我最大的问题是违反DRY原则。一切都被复制粘贴，但它是相同的信息。

2 个解决方案

#1

Why don't you just import models and views from previous apps, as if they were library functions? You can also inherit from other classes and add methods and attributes, or override them when necessary. Python has lots of OOP tools for these kinds of situations.

为什么不直接从以前的应用程序导入模型和视图，就好像它们是库函数一样？您还可以从其他类继承并添加方法和属性，或在必要时覆盖它们。 Python有很多针对这些情况的OOP工具。

#2

I'm not sure if/how django supports symlinks, but if it does a scheme along these lines (I'm using something similar with Google App Engine) would help at least minimizing the number of repos you need to manage and the cloning:

我不确定django是否/如何支持符号链接，但是如果它按照这些方式执行一个方案（我使用与Google App Engine类似的东西）将至少有助于最小化您需要管理和克隆的回购数量：

App1_v1
App2_v2
App2_v1
App3_v1
site.com/2012
    App1_v1 -> ../../App1_v1
    App2_v1 -> ../../App2_v1
site.com/2013
    App1_v1 -> ../../App1_v1
    App2_v2 -> ../../App2_v2
site.com/2014
    App1_v1 -> ../../App1_v1
    App2_v2 -> ../../App2_v2
    App3_v1 -> ../../App3_v1