On 11/18/2010 09:11 AM, Mike S. wrote:
Robby on Rails (Robby R.) was briefly a fan of the reverse side of
the coin - sticking half your app inside the database with PL/Ruby:http://robbyonrails.com/articles/2005/8
He’s now gone all quiet on that front so I guess he’s swallowed the ORM
shilling.
There is nothing wrong with using an ORM. The problem is that some
people have the insane idea that the application layer should be
responsible for maintaining referential integrity. Thee only other
thing that bothers me about ORMs in Ruby is that they don’t have very
good support for stored procedures. They all seem to expect you to use
dynamic SQL for everything, which would be fine if I did not already
have stored procedures that did everything in my database.
Writing your own pseudo-ORM is really not the best use of your time even
if it results in cleaner code in your application as opposed to manually
setting everything up. I wrote a bunch of classes to map my database’s
stored procedures in VB.net (This was for a .NET 2.0 application so no
Linq or Entity Framework.) while interesting because it provided me an
opprotunity to learn more about reflection in the language I am most
comfortable in, I recognize that using an ORM like Entity Framework
would have been more appropriate. Especially since Entity Framework
supports stored procedures at least if you are using MS SQL Server.
I also don’t see the big benefit of using instead of triggers to update
views that would otherwise not be updatable over an ORM.