Приложение Rails с доступом не по HTTP

Question

Гипотетический вопрос (на данный момент!)

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

Короче говоря, он идеально подходит для Rails ... за исключением того, что он не хочет быть веб-приложением. Возможно, он хочет интерфейс командной строки; или OS-собственный диалоговый интерфейс; или, возможно, он хочет представить себя в качестве ресурса для других приложений. Как бы то ни было - он просто не предназначен для представления себя через HTTP.

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

Мне интересно знать, каков будет лучший способ создать такого приложения. Вы бы лучше rails new non_web_app, чтобы построить скелет «бесплатно», затем написать какой-нибудь «нормальный» код Ruby, который require s config/environment - но тогда у вас есть много веб-центрированных различий, которые тебе не нужно? Или было бы лучше закатать рукава и собрать его из цельной ткани, взяв только те библиотеки, которые вам нужны, и вручную написав любую необходимую конфигурацию?

Если последнее, что именно необходимо необходимо для создания приложения на Rails, но без веб-битов?

Answer 1

Если вы хотите получить доступ к ORM Rails для разработки не-веб-приложения CRUD, просто включите ActiveRecord в ваш собственный скрипт на Ruby;вы избежите использования большого количества модулей Rails, которые вам, вероятно, не нужны (маршрутизация, генератор шаблонов, ...) Вот пример того, как это сделать .

Если вы предпочитаетечтобы получить полный стек Rails, не запускайте веб-приложение Rails на сервере приложений (WEBrick, Passenger, Mongrel, ...), чтобы избежать воздействия HTTP, и взаимодействуйте с вашим приложением с помощью задач или консоли rails.

Answer 2

Rails для веб-приложений.Это означает HTTP.Теперь вы можете упаковать веб-приложение так, чтобы оно работало на настольном компьютере, или использовать ActiveRecord с каркасом настольного приложения, например Monkeybars .

.

Answer 3

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

rails new non_web_app

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

Тогда вы можете просто удалить ненужные биты.... общедоступный каталог, структура представления в app, config / rout.rb и т. д. Вам нужно будет постепенно проверить эти изменения и убедиться, что удаление какого-то постороннего бита не приведет мир Rails к хаосу.