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 += '...').
