Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Note: this is from the spring of 2008, thus ancient in rails land.

(The title for this probably isn't as good as it should be, I cannot think of a better one)

I am about to revisit a startup idea and my platform of choice is Ruby on Rails. I've also recently started re-reading the book "Enterprise Rails" which suggests that you do not follow the Rails default conventions but instead separate out your layers into "physical" and "logical" components. This is the only book I have yet to see where this opinion is expressed; every other Rails book seems to just follow the "convention over configuration" mantra. In short the book suggestions you divide your app/ folder into the following:

  • app/models/physical (used for the actual .rb model files)
  • app/models/logical (used for web service APIs I believe)

and do the same with your controllers and other areas of the app. The book also advises not to use database migrations at all but use raw SQL scripts (and later on makes use of using SQL views and functions) under a separate folder that doesn't adhere to the Rails norm.

My question is whether or not I should worry about these things if I am just beginning to develop my application. Obviously the book advises that I do to avoid possible problems down the road, and the .NET developer in me wants to agree, but the Rails developer in me (still an infant) is telling me to just follow the "Rails Way" 100% since I'm still learning the framework and the Ruby language. I wonder how many successful Rails apps actually just follow the norm with all the models in app/models, all the controllers in app/controllers without any further segregation, and how many do some kind of "enterprise-y" architecture?

share|improve this question
You have to take into account really, that "Enterprise Rails" was published in 2008. So much has changed since then that it's probably a bad idea to follow the advice contained therein, except as a general guideline. –  Stephen Orr Aug 15 '11 at 16:49

4 Answers 4

up vote 7 down vote accepted

If you're just learning Rails, I'd go with the Rails way ("When in Rome, ..."). If you're worried that your startup may falter due to scalability issues down the road, I'd suggest you revisit your decision to use RoR. Solving scalability problems is hard enough in an environment you know well, you don't want to struggle with an unfamiliar one when you're under the gun. (Note that this isn't particular to Ruby, it's just as applicable to Python, Scala, Perl, C++ or any other language you don't know...)

share|improve this answer

Rail, fortunately or not, is not yet ready for enterprise applications. A friend of mine tried to force it to follow enterprise patterns and best practices, but the fact is that the models are tied closely to the persistence pattern. In a "true" enterprise application, the model used by the views and controllers talk with a separate model called the domain model. This contains the domain or business logic and connects to the persistence layer. Since Rails does not allow this separation (I know you can use Rack to fake this, but that is not trivial), it is decidedly not enterprise ready.

That said, Rails is wonderfully well suited for "small" applications (small is very relative in this situation).

Also my friend did try using the Rails 3 and found that it made many advances towards being enterprise ready, but has not quite arrived.

share|improve this answer
IMHO, Rails does not have required architecture to help you build an Enterprise application. Even Symfony (PHP fw) was built in a way to permit that, but Rails doesn't. –  hlegius Nov 16 '13 at 16:59

Depend what you mean by "enterprise" I guess. How many models and controllers are you expecting to have? I've worked on apps with around 30 models files and 10-15 controllers without running into any problems, but I could imagine if you had hundreds it might be a little harder to manage.

But even then, there are ways around that (plugins for example).

share|improve this answer
Well, that's the thing. The book's advice is to start out doing things "enterprise" even if you don't have many models (the author says that from personal experience the default way runs into issues as you get larger). –  Wayne M Apr 11 '11 at 15:13
@Wayne: Don't forget, YAGNI. I would suggest unless you see "immediate" (or "nearly immediate") need to have hundreds of models, then following the "Rails way" is probably the best solution. If you find yourself running against limitations or whatever, then refactor. –  Dean Harding Apr 11 '11 at 16:59

I'm working on ROR project which has 130 plus models, it works superb. I don't think it will be hard to manage if you follow the rules. keep skiny controller and fat model, write unit and functional test cases for each. that will help you to take control of whole project and will save your lots of testing time as well.

what is Enterprise application?

Enterprise applications are typically designed to interface or integrate with other enterprise applications used within the organization, and to be deployed across a variety of networks (Internet, Intranet and corporate networks) while meeting strict requirements for security and administration management.

As my experience says that rails can be scalable like other popular language and can be used to develop enterprise applications after all it depends on your organizations what are their requirements for their business.

Rails has so many advantage which must be consider while architect and has also no sql big data support it up to you how you manage these resources and take the decision accordingly.

Now Ruby 2.2 and Rails 4.2 released with several improvements in terms of performance, scalability, maintainability more stable and mature like other framework and language,

I will suggest you to check date while posted article, I will say Rails is ready for enterprise application (all world moving towards REST architecture and rails is by born has REST support).

share|improve this answer
I'm confused by this answer. Are you saying that the suggestion to split the physical and logical models is correct, or are you saying that by following the default conventions, you app is can be scaled to work in an enterprise? –  Jay Elston Apr 15 at 19:27
I mean following best practices of Rails / default conventions. In the latest Rails 4.2 version come up with concerns directory for controller and models make sure you use them better while design/programing. If we talk about my app that will definitely scalable it is associated with mobile client, BI anlystics etc. no problem so far, I keep refactoring things required ....its ready to scale up to work in enterprise. still will ask you to spend some time with latest rails 4.2 features and how that will useful, what things make Ruby2.2 much better than before...then take your decision. thanks –  Rameshwar Vyevhare Apr 16 at 10:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.