[Ironruby-core] General advice

Ivan Porto Carrero ivan at flanders.co.nz
Fri Jan 4 14:07:51 EST 2008


For the book I'm writing on IronRuby I'm deciding which way to go to
demonstrate how IronRuby can leverage the .NET framework.

The beginning of the sample application should implement some database
layer. My first instinct is to go with Linq-to-SQL and consume those classes
from a ruby application.
I have a problem with ActiveRecord that comes with Rails, because often it
doesn't allow me to the things I want to do out of the box. And when I'm in
App Dev mode I don't really want to think about customizing the framework
I'm using so that it fits my needs. I should just have to configure it and
start developing. For this reason I don't consider ActiveRecord to be
sufficient for most enterprise database systems and definitely not legacy
ones. I don't think it would be a good idea to let .NET devs jump to an ORM
that won't handle the more complex enterprise scenario's out of the box.
I'm thinking of writing a real ORM for Ruby ala NHibernate one that uses a
DataMapper with an IdentityMap backed by a Unit Of Work, when I'm finished
with the book. It should also have  Sql Generation that is highly optimized
for each platform it supports (not just say because mssql is from ms we
won't provide the best support for it we can) and maybe make it support
linq-to-sql syntax. Obviously I can't build that in 2 days so I'll have to
drop that idea for a while ;)

A second option I have in mind is rolling my own implementation of the
ActiveRecord pattern, using database reflection, an ADO.NET backend and
metaprogramming since it has a very limited scope for the book. I'm always
much in favor for a unit of work implementation for my dataaccess.

At this moment I'm favoring the Linq-to-Sql (C#) approach because it has
benefits :
1. I demonstrate interop with one of my own project assemblies and how you
can extend that using IronRuby.
2. I don't have to write my own ORM
3. I won't be stopped in my writing by features that haven't been
implemented yet.

The downside of that approach is that it will be hard to show an example
that makes real extensive use of metaprogramming.
A second concern I have for the Linq-to-SQL approach is that that will only
work on a windows box, because I don't think the mono-project has an
implementation already.

Then a last way of doing it would be to use ActiveRecord from the castle
project or SubSonic where the ActiveRecord implementation of the
CastleProject will be the one that handles most edge cases. The reason I
bring these 2 up is that I already got questions from people asking me to
put examples up on my blog about using those things  from IronRuby. At this
point I haven't put too much on my blog yet because I'm pretty busy writing.
And I think every week I wait I'm more close to being able to use as much
pure ruby as I can.

Any thoughts ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080105/18fff09e/attachment.html 

More information about the Ironruby-core mailing list