I am a .NET developer and I just had the chance to play with Ruby on Rails this weekend.
In .NET we separate layers of the application by creating separate class library projects. From the design pattern standpoint, do we have to do that in Rails too or is it just one whole project with everything in it?
2
You’ll find that Rails apps start as single repos. The more successful ones (Twitter, Square, many others) split into multiple codebases as they grow into that requirement. Those additional codebases can be daemons, services, gems, Rails Engines, or something else.
This refactoring into multiple projects isn’t done until it proves necessary, because YAGNI. Bifurcating your project on day 1 slows prototyping time, and prototyping speed is a key strength of Ruby and of Rails. You’ll want to keep in mind that creating or a class in Ruby costs almost nothing, as does breaking apart a well-desined class. Your pure Ruby code will live mostly under /app/ (app/models, app/views app/controllers, app/helpers) and /lib/. Your static assets, layered JS/Coffee includes, and CSS/Sass/etc includes are going to be in /app/assets.
Understanding why breaking apart a Ruby class is so easy requires a bit of reading on duck typing and the understanding that Ruby’s interfaces aren’t as ironclad as you might
be used to in a less dynamic environment.
Here are a few links that might interest you:
-
Brief description of duck typing (Yehuda Katz blogpost)
-
The inestimable Sandi Metz on how and why to design OO programs that are simple to read, to understand, and to change (2 hour Ruby Rogues podcast) (Her fantastic book)
-
Rails creator David Heinemeier Hansson on the asset pipeline and the code layout problems it ameliorates (RailsConf keynote video)
-
Making your own gem (Rubygems.org HOWTO)
Good luck with your projects!
0