Hi 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 ? Cheers Ivan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080105/18fff09e/attachment.html
Hi Ivan, I have some thoughts. I know I''ve been away from this list a while, sorry about that. On Jan 4, 2008 12:07 PM, Ivan Porto Carrero <ivan at flanders.co.nz> wrote:> Hi > > 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.Ultimately, we should be able to call any .NET lib from IronRuby. So to an extent I don''t think it matters what your pre-existing data access layer is written in, as long as it is valid .NET code. That said, if I were buying a book on IronRuby, I would want to know how Ruby approaches data access. I already know ADO.NET, and possibly the various.NET-based ORM frameworks. What I probably don''t know are the Ruby libraries like DBI.> 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.Regardless whether you consider ActiveRecord sufficient, alot of developers will want to know how to use ActiveRecord from IronRuby. I think you are missing an great opportunity if AR isn''t covered, along with what changes might be needed to get it to work with IronRuby. Besides, there are always the other ORM libraries that you can cover which may be a closer to what you think a good ORM should be: DataMapper - http://datamapper.org/ Sequel - http://sequel.rubyforge.org/ rBatis - http://ibatis.apache.org/docs/ruby/> 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 ? >If it were me, I''d avoid anything that required readers to use any language other than IronRuby. Good luck!> Cheers > Ivan > > > > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080104/26aa0f82/attachment-0001.html
Hi, Few Suggestions here. (1) Do Not Avoid Active Record at any cost. Active Record and Migrations should be covered in depth. SubSonic is working very hard to get major parts implemented in Asp.Net MVC and General Asp.Net soon. Plus... Subsonic is very famous due to Active Record only. Majority of Developers will jump into IronRuby to take full advantage of Ruby and Ruby on rails. As per "Rob Connery" he is suppose to write a book on " SubSonic and MVC ", you may talk to him about his coverage with MVC and get a rough idea about Subsonic and Active Record implementation in Asp.Net. (2) Start building an existing Startkerkit in IronRuby, along the way you explain IronRuby. A Real life approach will be highly appreciated. You get 3 advantages with it... (a) Existing Starterkits are discussed with a working site in VB and C# currently and hence are easy to discuss further. (b) Existing developers gets an idea about comparing dynamic language with C#/Vb. They will know what a clear syntax and ironruby code can do. How many coding lines are saved by comparing C# with Ironruby. (c) New Ruby developers entering IronRuby gets a treat of working example (3) Try to make IronRuby + Asp.Net a mission. Do not waste much efforts teaching Ruby in your book. Plenty of Ruby books are already available. Developers/Students will prefer to read a Book that implements Ironruby with Asp.Net and get it started immediately. (4) Since this is a first ever book on IronRuby... It would be better to get more and more suggestions that the Ruby community wants for a real life approach. There are plenty of hopes build up on IronRuby and your book should not let them down. Mr. John Lam, has taken a practical approach by choosing this RubyForge rather than Codeplex, since he wanted more and more developers to share. Taking the same approach will justify your efforts and get the real Ironruby out. (5) IronPython ( Few Chapters ) and Jruby books are also available as a reference. (6) Do not waste pages explaining the advantages of DLR , Asp.Net and .Net framework. You can always give links for further reference. (5) I am just pointing a very good blog, that clearly requests MSFT to stop wasting much time on C# 4.0 and rather send few more hands to IronRuby team. They all are banking on IronRuby. http://codebetter.com/blogs/jeremy.miller/archive/2008/01/02/c-vnext-take-2.aspx I am just suggesting it, since i have read plenty of books and know what helps in real life. Wrox publisher''s " Beer StarterKit " is very famous and preserved on shelf. You can also take inspiration building such a kit with Ironruby or other existing Kits, which can help in Real Life. Learn... Gain... and Earn... Should be the motto of the book. After all.... you are the author... you are the better judge. Thanks for listening me. SoftMind. -- Posted via http://www.ruby-forum.com/.
Thanks for that. I can''t believe I didn''t know about DataMapper and rBatis, those seem like a better fit to what I want. I can follow your reasoning on ActiveRecord and it does have some weight for me, most people will be using active record because it comes with rails. I guess I could take some relevant snippets from that source code to illustrate how it has been done, because i wanted to use a model layer as an example of metaprogramming. I''ll have a play with the ones you just proposed and maybe cover one in addition to ActiveRecord so that readers know there are options. The Sequel one looks like a nice and easy one to use. At this point I''m only planning to talk about using another .NET language for illustrative purposes but I want to create a pure ironruby solution that''s for sure. However talking about IronRuby wouldn''t be complete without talking about the Iron in IronRuby and highlighting some of the interop possibilities there are too. Because suddenly you''re not limited anymore to libraries in your favorite language but you can use libraries from a collection of languages and a more vast community. That being said about 99.5% of the code samples will be Ruby. The book will take the reader through building an application built with IronRuby that leverages most of the .NET technologies like WPF, Silverlight, ASP.NET MVC, Webforms etc. I don''t really want to spend a lot of time explaining rails, because there is also plenty of information available about rails, but i will show that you can do with rails and IronRuby. I''ll also demonstrate how gems can make your life easier etc. A downside of showing WPF is that the reader won''t be able to run those samples on mono, or will he? Keep the feedback coming, I like it :) On Jan 5, 2008 7:50 PM, Softmind Technology <lists at ruby-forum.com> wrote:> Hi, > > Few Suggestions here. > > (1) Do Not Avoid Active Record at any cost. Active Record and Migrations > should be covered in depth. SubSonic is working very hard to get major > parts implemented in Asp.Net MVC and General Asp.Net soon. Plus... > Subsonic is very famous due to Active Record only. Majority of > Developers will jump into IronRuby to take full advantage of Ruby and > Ruby on rails. > > As per "Rob Connery" he is suppose to write a book on " SubSonic and MVC > ", you may talk to him about his coverage with MVC and get a rough idea > about Subsonic and Active Record implementation in Asp.Net. > > (2) Start building an existing Startkerkit in IronRuby, along the way > you explain IronRuby. A Real life approach will be highly appreciated. > You get 3 advantages with it... > > (a) Existing Starterkits are discussed with a working site in VB and C# > currently and hence are easy to discuss further. > > (b) Existing developers gets an idea about comparing dynamic language > with C#/Vb. They will know what a clear syntax and ironruby code can do. > How many coding lines are saved by comparing C# with Ironruby. > > (c) New Ruby developers entering IronRuby gets a treat of working > example > > (3) Try to make IronRuby + Asp.Net a mission. Do not waste much efforts > teaching Ruby in your book. Plenty of Ruby books are already available. > Developers/Students will prefer to read a Book that implements Ironruby > with Asp.Net and get it started immediately. > > (4) Since this is a first ever book on IronRuby... It would be better to > get more and more suggestions that the Ruby community wants for a real > life approach. > > There are plenty of hopes build up on IronRuby and your book should not > let them down. Mr. John Lam, has taken a practical approach by choosing > this RubyForge rather than Codeplex, since he wanted more and more > developers to share. Taking the same approach will justify your efforts > and get the real Ironruby out. > > (5) IronPython ( Few Chapters ) and Jruby books are also available as a > reference. > > (6) Do not waste pages explaining the advantages of DLR , Asp.Net and > .Net framework. You can always give links for further reference. > > (5) I am just pointing a very good blog, that clearly requests MSFT to > stop wasting much time on C# 4.0 and rather send few more hands to > IronRuby team. They all are banking on IronRuby. > > > http://codebetter.com/blogs/jeremy.miller/archive/2008/01/02/c-vnext-take-2.aspx > > I am just suggesting it, since i have read plenty of books and know what > helps in real life. Wrox publisher''s " Beer StarterKit " is very famous > and preserved on shelf. You can also take inspiration building such a > kit with Ironruby or other existing Kits, which can help in Real Life. > > Learn... Gain... and Earn... Should be the motto of the book. > > After all.... you are the author... you are the better judge. > > Thanks for listening me. > > SoftMind. > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20080105/3d758af2/attachment.html