发布时间: 2013-06-13 22:08:00
checkout this post: http://blog.jupo.org/2011/07/30/rails-quick-start-for-djangonauts/
I recently started a new role at a Ruby on Rails shop, which as a long time Django specialist was a really interesting opportunity. There’s a lot of competition between the two frameworks’ communities, ranging from friendly rivalry and respectful admiration at the mature end of the scale, to all out fanboy fuelled flame-wars at the other.
After you wade through the rivalry, the common wisdom voiced is that they’re conceptually the same. If you know Python, go with Django and if you know Ruby, go with Rails. After spending several months with Rails I can attest to this being true. At a bird’s-eye view both frameworks contain almost identical concepts, implemented with different philosophies stemming from the ideals expressed by the languages they’re written in. Both frameworks provide a vastly superior approach to security, modularity and rapid development than their predecessors do.
An interesting question to ask would be: which would be the best framework to choose, not knowing either language? It would be naive of me to believe I am unbiased, but I would certainly recommend Django over Rails. The relative strictness of Python and explicitness of each component in Django, compared to the implicit magic in Rails, is simply much more geared towards creating large-scale systems in a sane and transparent way. To Ruby’s credit though, I have developed a real admiration for the language itself, and have continued using it in my own projects - but that’s a topic for another post.
Considering how similar the two frameworks are component-wise, one thing I did miss was a side-by-side cheat sheet for working out what each of the concepts were in Rails that I already knew well in Django. I’ve put one together below to help out anyone who might be picking up either framework while already knowing the other. For clarity, I’ve also included descriptions of each type of component, for those who haven’t used either framework.
| Django | Ruby on Rails | |
|---|---|---|
| URL patterns | Routes | Regular expression definitions for each type of URL and what part of the web site they map to. |
| Views | Controllers | The units of code that the above regular expressions map to, that perform application logic and pass data to a rendering layer. |
| Templates | Views | The rendering layer that is given data from the code described above, and performs display logic typically wrapped around HTML code. |
| Template tags (built-in) | Embedded Ruby | The flow-control language that can be used in the rendering layer. |
| Template tags (custom) | Helpers | The system for defining custom functions that can be used in the rendering layer. |
| Models | Models | The data-definition layer that maps classes to database tables - the ORM. |
| Managers | Scopes | The way to extend the ORM to define custom database queries. |
| Management commands | Rake tasks | Scripts for performing administrative tasks via the command line. |
| Project | App | An entire application built with the framework. |
| App | Plugin | The way in which all components in the framework can grouped together in separate areas of functionality. |
| South (third-party) | Migrations | The system used for automatically applying changes in the ORM definition to the underlying database tables, such as adding and removing columns. |
| Admin | RailsAdmin (third-party) | A web-based interface for authenticating administrative users and providing CRUD tools for managing data. |
|
The following table lists software that aren't part of Django or Rails, but are core parts of the Python and Ruby eco-systems, and go hand-in-hand with using either framework. |
||
| Python | Ruby | |
| Virtualenv | RVM | The system used for running isolated environments bound to a particular language version, combined with a set of installed libraries. |
| PIP | Bundler | The package manager for installing libraries. |
| WSGI | Rack | A standard specification for applications to interface with HTTP, allowing for a single application entry point and middleware to be implemented. |
| Fabric | Capistrano | A system for automating tasks on remote servers from a local machine, typically as part of a deployment process. |
Not all of these pairings are a perfect one-to-one match conceptually, but should be good enough to get an overall view of what each concept is within both frameworks.