Как наилучшим образом организовать компонент правил системы Django? - PullRequest
4 голосов
/ 17 августа 2010

Я проектирую (и в конечном итоге пишу) систему в Django, которая состоит из двух основных компонентов:

  1. Менеджер игр: по сути, это часть для ввода данных.Доверенные (непубличные) пользователи будут вводить информацию об игровой системе, такую ​​как опции, которые может иметь игрок.Интерфейс для этого - исключительно консоль администратора Django, и он ничего не «делает», кроме как хранит информацию.
  2. Менеджер персонажей: это потребитель вышеуказанных данных.Публичные пользователи будут создавать персонажей в ролевых системах, определенных выше, используя опции, введенные этими доверенными пользователями.Это отдельное приложение в проекте с точки зрения Джанго.

Есть одна часть, которую я, однако, не уверен, куда поместить, и это "правила", которые связаны с каждой игрой.По сути, для каждой игры, помещенной в первое приложение, существует набор предварительных условий, ограничений и другой бизнес-логики, характерной для этой игры.(Существует также аналогично структурированная логика, которая будет общей для всех игр.) Логика будет закодирована в Python, а не введена пользователем.

Эта логика используется впроцесс проверки конкретного персонажа, но он связан * с конкретной игрой * 1014 и должен быть заменен динамически.Это отдельное приложение или оно должно быть привязано к формам Диспетчера персонажей?Или это может быть и то и другое?

Это первое приложение Django, которое я создал с нуля (а не пережевывая чужой код), и я новичок в философии Python для загрузки, так что явсе уши на этом.

Заранее спасибо.

Ответы [ 2 ]

1 голос
/ 17 августа 2010

«правила», связанные с каждой игрой.

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

Это часть игрового приложения.

Существует также аналогично структурированная логика, которая будет общей для всех игр.

Это часть игрового приложения.

Эта логика используется в процессе проверки конкретного персонажа, но связана с конкретной игрой.

Правильно. Это часть игрового приложения. Персонажи связаны с одной или несколькими играми.

должна ли валидация быть привязана к формам Диспетчера персонажей?

Формы персонажей могут иметь правила очистки данных, которые зависят от Игры.

1 голос
/ 17 августа 2010

Я бы создал подкаталог с именами правил в приложении с игровой логикой и создал бы модуль, названный в честь каждой игры, которую вы хотели бы обслуживать.Затем создайте общий интерфейс для этих модулей, который будет использоваться вашими играми, и импортируйте соответствующий модуль правил по имени (если ваша игра называется adom, то просто __import__('rules.adom') внутри основного игрового движка и вызовите специфичные для игры методы.

Если в ваших играх не создаются собственные модели и представления, то, похоже, нет причин создавать конкретные приложения для каждой из них. Это деликатный вопрос, поскольку используемый код основан на данных, хранящихся в базе данных.Не думаете ли вы о том, чтобы хранить дополнительные игровые скрипты внутри базы данных и затем exec к ним? Это кажется более естественным: игра представляет собой набор данных и дополнительных скриптов, связанных с этой игрой.

...