In responding to comments by Daniel Spiewak, creator of the ActiveObjects persistence framework, Gavin King contrasts the configuration-by-convention style of database mapping—used, for instance, in Rails' ActiveRecord component—with the more explicit mapping declarations used in Hibernate and the Java Persistence API:

To solve this non-problem of mountains of XML, Daniel was inspired by Ruby's ActiveRecord. The code example he gives is the following:

class Person < ActiveRecord::Base  
   belongs_to :company  
end

class Company < ActiveRecord::Base  
   has_many :people  
end

At this point, most developers are thinking um, ok, so how the hell am I supposed to know what attributes a Company has by looking at my code? And how can my IDE auto-complete them?

Of course, the Rails folks have a quick answer to this question Oh, just fire up your database client and look in the database!. Then, assuming that you know ActiveRecord's automagic capitalization and pluralization rules perfectly, you will be able to guess the names of the attributes of your own Company class, and type them in manually.

King shows a comparable declaration using Hibernate:

@Entity
public class Company extends Entity {  
   private String name;  
   private String tickerSymbol;
   @OneToMany private Person[] people;

   public void getName() { return name; }  
   public void setName(String name) { this.name = name; }

   public void getTickerSymbol() { return tickerSymbol; }      
   public void setTickerSymbol(String tickerSymbol) { this.tickerSymbol = tickerSymbol; }

   public Person[] getPeople() { return people; }
   public void setPeople(Person[] people) { this.people = people; }
}

King notes that the Java class is much more verbose than the Ruby/ActiveRecord entity class, since in the appropriate property accessors are added to the Ruby class dynamically, based on the database columns. Still, King believes that the more explicit Java code is easier to work with:

Somehow, excitement about the Ruby language has warped their perceptions to such an extent that these people actually believe that this is a good thing!...

I really don't think this code is significantly more complex or difficult to type than the ActiveObjects version (in fact, in a modern IDE, it probably requires fewer keystrokes to produce). Even better, I don't need to use any funny API to instantiate this class. I can just use new and be done with it.

And I think the code is a lot clearer and more explicit than the ActiveRecord version. Object orientation was very much intended for modeling business domain objects like Company and Person. It seems more than strange that Rails would essentially delegate the business domain model to the database.

What's your take on working with more verbose, but possibly more explicit, code versus relying to a great extent on automatically generated code and artifacts?

// First piece of data I'm trying to access
String value1 = object.value1;

// Next piece of data I'm trying to access.
// Hold on. I need to use a getter here. Aha,
// I guess that reveals something of the way
// things are implemented. 
String value2 = object.getValue2();

>>> class FancyX(object):
	def _get_x(self):
		print "getting X"
		return self.__x
	def _set_x(self, val):
		print "setting X to", val
		self.__x = val
	# We won't let them delete X
	X=property(_get_x, _set_x, None, "property demo")

>>> f=FancyX()
>>> f.X
getting X

Traceback (most recent call last):
  File "<pyshell#61>", line 1, in <module>
    f.X
  File "<pyshell#59>", line 4, in _get_x
    return self.__x
AttributeError: 'FancyX' object has no attribute '_FancyX__x'
>>> f.X=3
setting X to 3
>>> f.X
getting X
3
>>> del f.X

Traceback (most recent call last):
  File "<pyshell#64>", line 1, in <module>
    del f.X
AttributeError: can't delete attribute

>>> f.y

Traceback (most recent call last):
  File "<pyshell#65>", line 1, in <module>
    f.y
AttributeError: 'FancyX' object has no attribute 'y'
>>> f.y=4 # no property here
>>> f.y
4
>>> del f.y