В Rails объекты должны быть ограничены теми, которые будут иметь вид и контроллер?

Question

Я боролся с проблемой дизайна, и я признаю, что я новичок в OOP и RoR, поэтому я уверен, что это будет очень просто.У меня есть приложение, в котором я читаю из текстовых файлов в различных форматах, чтобы анализировать информацию, связанную с руками в покере.Итак, у меня есть три объекта:

• Файловый объект.Здесь хранятся имя и путь к файлу и некоторые другие атрибуты, а также функции, связанные с чтением из файлов.Это MVC, потому что я могу добавить файл и автоматически обновлять его, или я могу просто анализировать информацию из файла на лету.

• Объект покерной руки.По сути, это просто хранит информацию о том, кто играл в покер, и каковы были действия и результаты.

• Анализатор.Это читает внешние файлы JSON с различными шаблонами регулярных выражений в зависимости от типа файла, который читается.Он также содержит некоторую базовую информацию о состоянии машины в файле JSON, поэтому большая часть логики удаляется из анализатора.

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

Так что это должен быть его собственный объект, находящийся внутриобъект файла, или я не вижу другой альтернативы?

Answer 1

Решение о том, должно ли что-то быть буквой "M" в MVC, должно основываться на наличии постоянных (управляемых базой данных) данных.

Для моделей не требуется контроллер или представления, а также контроллерыне нужно сопоставлять один на один с моделями.Тем не менее, общий подход "RESTful API" приводит к сильной модели <=> соответствия контроллера.

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

Answer 2

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

Я бы оставил ваш парсер вне File и поместил бы его в lib /.

Answer 3

Но потом я понял, что у него нет V или C и, возможно, он не подходит для Rails.

Тот факт, что у него нет V или C, не имеет значения, на мой взгляд.

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

Относительно того, принадлежит ли он в lib или app / models - я смотрю на это так:

Если это часть вашего приложения, оно относится к приложению / моделям. Если оно не является частью вашего приложения, как внешняя библиотека, не помещайте его в app / models - поместите в папку lib.

Answer 4

Я использую, чтобы позволить классам, которые реализуют доменную логику, в папке моделей. Вы должны знать, что они не будут автоматически перезагружены, если они помещены в папку / lib.