Как организовать приложение Rails

Question

Впервые я создаю довольно сложное приложение Rails.

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

Как, например, Spree Commerce. У них есть общая папка, а внутри - разные приложения (API, ядро, администратор и т. Д.). Как это сделать, и это лучший способ сделать это?

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

спасибо

Answer 1

Кстати, название вашего вопроса немного сбивает с толку. Rails, используя соглашение по конфигурации, определяет «как организовать приложение Rails». Я думаю, что ваш вопрос скорее о том, как архитектор ваше приложение, а не что-нибудь специфичное для Rails. Может подправить заголовок?

Кроме того, не зная больше деталей о вашем проекте, на этот вопрос сложно ответить, но я попробую.

Все приложения должны начинаться с простого, если вы считаете (как и я), что вы должны начать с создания самой простой вещи, которая могла бы работать . Учитывая это, поскольку вы используете Rails, то, по всей вероятности, проще всего будет структурировать ваше приложение как ванильное приложение Rails 3. Это, вероятно, (я говорю «вероятно», потому что я не знаю каких-либо подробностей о приложении) позволит вам быстро запустить и запустить бета-версию вашего приложения, не беспокоясь о сложностях, которые на данном этапе разработки вашего проекта не проблема.

Если вам нужно создать API на основе XML или JSON, тогда Rails сделает это очень простым , используя стандартную среду, которая позволит вам больше думать о дизайне API чем то, как его кодировать, и это дизайн API, который является наиболее важным, чтобы правильно понять в первую очередь.

Точно так же ваш админ-сайт может быть частью одного и того же приложения только в другом пространстве имен. Если позже вы обнаружите, что хотите, чтобы оно было отдельным приложением, вы можете сделать это (возможно, вы могли бы использовать великолепный API, который вы разработали, чтобы облегчить это), но зачем создавать его с такой дополнительной сложностью (и, следовательно, с большим временем разработки) ) во-первых, если у вас нет веских причин для этого?

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

Даже если ваше приложение столь же безумно успешно (и я надеюсь, что это так!), То, как доказал Твиттер, все еще возможна ре-архитектура вашего приложения, в то время как продолжение работы существующего сервиса все еще возможно. Просто придерживайтесь заявления Кнута и все будет в порядке.

Что касается материалов для чтения, то это сложно. Для меня многие классические идеи по XP и гибкой разработке научили меня тому, как подходить к разработке программ и приложений. Я бы также проверил эту тему StackOverflow на предмет вдохновения для книг.

Удачи!

Answer 2

Spree использует Rails ' Railties ( Rails :: Engines ). Rails введены в Rails 3, чтобы сделать его более модульным и легко расширяемым. Rails 3 сам по себе является набором Railties (ActiveSupport, ActiveModel, ActiveRecord и т. Д.).

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

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

Answer 3

ИМХО, я буду создавать очень сложные проекты как одно приложение.У меня есть основания полагать, что Spree и Radiant строятся под отдельными приложениями, поэтому под предлогом своих сообществ с открытым исходным кодом участники могут легко вносить код, не затрагивая основные данные и основные направления работы приложения.

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

Answer 4

Вот что удерживало меня в здравом уме в течение нескольких лет разработки RoR:

1. Я использую Rails Engines, но держу их в той же кодовой базе, что и основное приложение.Вот хорошее начало для модульного приложения Rails: https://github.com/shageman/the_next_big_thing

2. Везде, где я могу, я стараюсь уменьшить сцепление и использовать композицию, чтобы сделать вещи легко тестируемыми, многоразовыми и ремонтопригодными.Это помогает в конечном итоге извлечь модуль или движок как отдельный драгоценный камень.Составление выполняется с помощью маршрутов (монтирования), наложения каталогов (ресурсов), внедрения зависимостей или конфигурации.

3. Если мне не нужно повторно использовать движок, я помещаю его в тот жекодовая база в качестве основного приложения, которое представляет собой единицу развертывания.Благодаря этому мне не нужно переключаться между проектами в моей IDE.В то время как в среде разработки любые изменения в коде движка мгновенно обнаруживаются механизмом перезагрузки Rails.