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

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

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

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

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

Благодарю вас

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

Удачи!

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

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