4

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?

Improve this question
1
  • 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.
    – Steve Hill
    Aug 15, 2011 at 16:49

3 Answers 3

Reset to default
7

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...)

Improve this answer
4

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.

Improve this answer
1
  • 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.
    – hahaha
    Nov 16, 2013 at 16:59
1

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).

Improve this answer
2
  • 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 Molina
    Apr 11, 2011 at 15:13
  • 3
    @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, 2011 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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