From: Richard Conroy Date: 2010-06-08T20:39:55+09:00 Subject: Re: Looking for ORM for 'legacy' database. --000e0cd1fe36492e270488833bd0 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 7, 2010 at 11:05 PM, Dave Howell wrote: > > On Jun 6, 2010, at 15:55 , Phrogz wrote: > > > > I encourage you to give Sequel a long, hard investigation before > > discounting it. > > Oh, believe me, Sequel has never been 'discounted.' Just my own digging had > Sequel as one of the three top candidates on my list. > I have looked at Sequel myself and it does seem very compatible with your needs. There is also the Ruby database connectivity library DBI (IIRC part of the standard lib), which is just a basic database connectivity/SQL library. However Sequel seems to have superceded in common use. > I've got a number of scripts already that drive data in and out of Postgres > 'directly,' but I've been assuming that once I add a templating engine and > web adapter, that they'll be much easier to use if I'm giving them Ruby > objects that look like what ORMs make, rather than a big array or some such. > Well not necessarily. Type conversion (between SQL data types & Ruby, or any language for that matter) is a necessary part of any DB communication. Ruby is dynamically typed, so each ORM/DB connectivity API has a lot of options in this regard. For instance ActiveRecord builds up/completes your models by inspecting your DB. In practice the more popular APIs tend to have fairly array-like or intuitive type conversion. > > I still haven't figured out what, exactly, a Domain Model will do for me, > or even exactly what it is, but I'm not (deliberately? consciously?) trying > to throw those advantages away. Thanks for the links. > Having model objects saves a LOT of coding. It gives you intuitive places to put validation. It integrates well into testing apis and makes the client side coding very tidy and natural. In addition you can get a lot of free features if you use an API like DM or AR (like SQL injection protection, or form helpers). Do not underestimate the saving in lines of code. regards, Richard -- http://richardconroy.blogspot.com --000e0cd1fe36492e270488833bd0--