Подходит ли структура сайтов Django для обслуживания сайтов с другой структурой логики и моделей? - PullRequest
0 голосов
/ 04 марта 2011

Я работаю над приложением, которое было написано другими людьми. Он активно использует каркас сайтов для обслуживания двух разных игровых сайтов. Эти сайты работают с одним и тем же кодом в одной базе данных:

class Entry(models.Model):
    headline = models.CharField(max_length=100)
    body = models.TextField()
    created = models.DateTimeField()
    creator = models.ForeignKey(User)

    # Site1 fields
    best = models.BooleanField()
    is_editor_post = models.BooleanField()
    site1_views = models.IntegerField()
    cnt_comments = models.IntegerField()
    last_edit = models.DateTimeField()
    editor = models.ForeignKey(User)
    tags = models.ManyToManyField(Tag)

    # Site2 fields
    category = models.ForeignKey(Category)
    blog = models.ForeignKey(Blog)
    site2_views = models.IntegerField()

class Game(models.Model):
    name = models.CharField(max_length=100)
    description = models.TextField()
    genre = models.ForeignKey(Genre)
    release_date = models.DateField()
    platform = models.ForeignKey(Platform)

    # Site1 fields
    mark = models.IntegerField()
    badges = models.ManyToManyField(Badge)
    badges_updated = models.DateTimeField()

    # Site2 fields
    requirements = models.CharField(max_length=255)
    status = models.IntegerField()
    has_news = models.BooleanField()
    has_articles = models.BooleanField()
    has_screenshots = models.BooleanField()

    class Meta:
       permissions = (
           ('site1_add_game', 'Site1/Can add game'),
           ('site2_add_game', 'Site2/Can add game'),
       )

Как видите, есть куча полей, бесполезных для одного из сайтов. Кроме того, мы не используем разрешения по умолчанию, а вместо этого создаем свои собственные. Это связано с тем, что пользователи совместно используют два сайта, и одно использование может иметь право добавлять игры на обоих сайтах, в то время как другой пользователь может добавлять их только на сайт2.

Существует также много кода в представлениях, моделях и методах менеджера, таких как:

def get_related_entries(self):
    if settings.SITE_ID == 1:
       # code for finding related entries on site1
    elif settings.X_SITE_ID == 2:
       # code for finding related entries on site2
    return entries

Так что, когда я работаю над кодом сайта1, поля и код с сайта2 меня просто смущают. Если я добавляю функцию на первый сайт, чаще всего мне не нужна такая функция на другом. Также мне, вероятно, придется написать третий сайт, и они хотят, чтобы этот сайт работал с тем же кодом и базой данных. Зачем? Потому что они думают, что это позволяет повторно использовать код и обмениваться контентом между различными сайтами. Это звучит очень хорошо, и действительно есть куча кода, который часто встречается между сайтами. Но есть также очень много различий в логике сайтов и структуре моделей, чтобы запускать их в одном коде.

Код очень сложно поддерживать, и он выглядит некрасиво и не просто. Решением может быть разделение общих приложений и приложений для конкретного сайта. Но почти все приложения имеют специфичный для сайта код. Думаю, было бы намного проще, если бы у меня было два разных проекта, каждый со своим собственным кодом и моделями.

Итак, подходит ли здесь фреймворк для сайтов? Когда это подходит? Почему Django "настоятельно поощряет" , который он использует?

1 Ответ

1 голос
/ 10 марта 2011

Несмотря на то, что у меня нет большого опыта работы с каркасом сайтов, я думаю, что это имеет смысл, когда вы хотите использовать один и тот же интерфейс администратора для всех сайтов.И это требование, которое вы даже не упомянули.

Недавно я подумал об его использовании, но после некоторого начального кодирования я решил отказаться от него.Все усложнилось очень быстро.Если заявления везде, дополнительные поля, которые мне в основном нужны только на одном сайте, обработка разрешений выглядела сложно, почти все, что вы упомянули.

Я уверен, что - это сценарии использования дляструктура сайтов, но в случае сомнений я бы пошел на отдельные проекты с повторно используемыми приложениями, где модели могут быть разделены на подклассы при необходимости.

...