Rails - где (каталоги) помещать модели, которые не являются активными

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

Мы боремся с тем, где их поставить.

Должны ли мы:

app/models/domain

или

app/domain/models

или, возможно,

app/models   # Business Models
app/models/ar # Active Record Models

или, возможно,

app/models/domain/   # Business Models
app/models/domain/ar # Active Record Models

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

Если мы будем рассматривать объекты как объекты службы, мы могли бы иметь

app/models/service-object

app/models/ # For plain active record

Еще один способ спускаться не будет в приложении, например.

/service_objects

вместо

/app/models/service_objects

Предположительно, если нам нужен доступ через приложение rails, мы лучше используем приложение /, чтобы использовать соглашение по конфигурации.

Ответ 1

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

Я обычно резервирую app/models для моделей на основе ресурсов. Если эта модель представляет собой ресурс, который создается и управляется вашим приложением, он идет здесь. Не требуется поддержка AR или db.

Если модель поддерживает согласованную функциональность, но зависит от параметров, я даю им каталог верхнего уровня в приложении. Например, app/mailers app/observers и т.д. Однако, если у вас есть один ресурс, который требует наблюдателя, возможно, нет смысла иметь директорию app/observers с одним файлом в нем.

Все остальное идет в lib. Есть несколько причин, почему это предпочтительнее.

Вы можете выбрать, когда требовать файлы в lib. Вы можете быть более избирательным, какие файлы загружаются при запуске вашего приложения. Если вы поместите все в app/models, у вас нет детализации над тем, что загружается.
Имена, расширяющие ваши модели по мере роста вашего приложения, проще в lib. Конечно, вы можете использовать пространство имен в app/models, но несколько слоев вложенности в app/models всегда заканчиваются неприятными. Лучше всего сохранить пространство имен в lib.
Уборка дома значительно облегчается, когда у вас есть вещи в их функционально правильном месте. Это не ресурс? Это не наблюдатель? Должно быть в lib. Вся причина, по которой вы задумываетесь над этим, заключается в том, чтобы обеспечить открытость разработчикам по линии.

Ответ 2

Для объектов службы вы обычно будете иметь их непосредственно в каталоге приложения app/services/. Рабочие и сериализаторы также следуют этому шаблону app/workers/ app/serializers/. Что касается ваших моделей, которые не являются AR, вы все равно можете вставлять их в каталог моделей. Это просто мое занятие.

Ответ 3

Если это модели, вы должны поместить их в app/models, поскольку этот каталог предназначен для моделей, а не только для подклассов ActiveRecord.

Ответ 4

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

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

В конце концов, это не имеет большого значения. Выберите одно и согласитесь с остальными членами вашей команды. Перемещение вещей должно быть довольно простым, особенно если вы добавите все, что решите использовать для пути загрузки для своего приложения ($LOAD_PATH += '...').