OK, lets take this one at a time.
The point of an ORM is usually to decouple your domain model from the database. Whilst this isn't strictly the case with ActiveRecord, that is a limitation of the Active Record pattern, not ORM in general. However, even with ActiveRecord, it enables you to treat your domain objects like any other object, i.e.:
Originally Posted by neobuddah
I appreciate the point about query speed (though I question the 100x slower claim), however I do not think that an "optimise first" approach is a good thing. Come up with a strong design first, optimise later. Get a working application then think about tuning it where needed. If speed is of the utmost importance, use direct SQL instead of the built-in ActiveRecord methods. However, you should still encapsulate this as a class method on your domain object. E.g.
@people = Person.find( :all )
@people.each do |person|
@people = Person.optimised_find( some_params )
self.find_by_sql("SOME QUERY HERE")
I can't answer that question as I have never needed to do something so complex, but I can tell you that if there isn't anything built into ActiveRecord that does what you need, or does it quick enough, there is nothing stopping you from running SQL directly. You can even get access to the underlying connection adapter if you need to.
Ah, well I may have that wrong. From chatting to ruby bods, it seems that a lot of apps are quick builds that have one or two tables with limited joins. How well would RoR/ActiveRecord handle left/right joins across 10 tables?
ActiveRecord is there to make your life a lot easier in general, but it doesn't prevent you from using SQL when you need it.
You should always separate your business logic from your output, and Rails does this. Consider the following...
Oh. I mean, I'm not an overly advanced OOP programmer, but I thought it was a good thing to seperate the business logic and final output? I personally use XSL for my presentation logic after outputting straight XML. This has allowed me the flexibility and power to do things such as quickly change between HTML4/XHTML/Text/JSON/YAML and have my app act as a XML-RPC/SOAP resource.
The Model (Business Logic):
The model includes a custom finder method for easily finding all active users.
class User < ActiveRecord::Base
self.find(:all, :conditions => [ "status = ?", 'active' ])
Controller (Application Control Flow):
The View (template):
class UsersController < ActionController::Base
# maps to http://myapp/users/list_active
@users = User.find_active_users
As you can see the template contains no business logic whatsoever, and only the simplest of presentation logic (loop through each user and display the user name and description). The controller instructs the model to load all active users and makes the resulting collection available to the view.
<% @users.each do |user| %>
<h2><%= user.name %></h2>
<p><%= user.description %></p>
<% end %>
To improve separation, advanced presentation logic can be wrapped up in view helpers that are automatically available in the view.
When it comes to web applications, you basically have two options: XML or HTML. What else what you need for a web application? Rails is after all a web framework, and it offers you both of the above. The XML builder style templates is a lot easier for building XML documents, such as RSS feeds. Having an XML feed is simply a case of having a separate action.
The XML builder syntax sounds interesting. I'm currently passing objects to a renderer at the moment which are converted to XML without me having to do anything. Is this similar to what its doing?
I think its the fact that it ties you to HTML, which can be a limitation. Especially when you're creating an app that might have unexpected results. A short while ago RSS/ATOM wasn't that big, so everyone output straight HTML. Now they're having to back-track and create seperate output logic to cope with the rise in RSS/ATOM use. Seperating out the HTML from the View logic means you can switch between output formats without much overhead.
So in addition to the users example above, we might have:
Then, in our template, users_rss.rxml (the .rxml extension indicates this is an XML builder template, and Rails automatically ensures the correct content-type header is sent):
# in the controller...
@users = User.find(:all)
The above is just small XML example, and would produce for example:
@users.each do |user|
xm.name( user.name )
xm.description( user.description )
More information on that here.
I've not really used XSL with Ruby but I did find this:
Yes, I must have. I'll check further on those. Anything that will do quick XSL translation?
As far as ORM patterns go, ActiveRecord is the simplest. Propel is not a good comparison as it does not use the ActiveRecord pattern, it uses the Data Gateway patterns I think (see Martin Fowler, Patterns of Enterprise Application Architecture).
Yes. I try to keep with very straight-forward SQL when available. Although it is nice to use the odd MySQL or SQLite feature.
Maybe I have missunderstood the benefits of ActiveRecord. I only know that without any ORM I've managed to save myself lots of time and effort by rendering db query results directly to XML.
When putting the data into the db I've always found that straight SQL is much easier than ORM methods, and once the stuff's in there, I've no need to manipulate it when pulling it back out. ORM seems redundant when you think of it like that, IMHO. Maybe I've got things wrong?
Do you really think a SQL INSERT statement is easier than this:
Or even shorter:
@user = User.new
@user.name = 'Luke Redpath'
@user.email = 'email@example.com'
@user.age = 23
@user.username = 'lukeredpath'
@user = User.create(
:name => 'Luke Redpath',
:email => 'firstname.lastname@example.org',
:age => 23,
:username => 'lukeredpath'
The easiest thing to do is post in this forum and ask for specific examples.
Still, it would be useful if there were a good PHP to Ruby tutorial, like the ASP to PHP ones in the old days.