4 ms·

As someone who has developed in Java, .Net, PHP, Python, Node.js, and Ruby on Rails for web projects, I must say what sells me on RoR is the nature of the langu

As someone who has developed in Java, .Net, PHP, Python, Node.js, and Ruby on Rails for web projects, I must say what sells me on RoR is the nature of the language and ActiveRecord. My god, ActiveRecord is AMAZING. Sometimes I just don't have the option to build something in Rails(for example building internal API's that have to be written in Java for a number of reasons), but given the choice I will choose a Ruby or RoR app every single time because of ActiveRecord and the way the language functions. I know there are lots of ActiveRecord style clones in other languages, but they just feel completely lacking when compared to the real ActiveRecord and all it's extensions.

vidarh 14y ago
I find it peculiar that anyone would describe ActiveRecord that way. In my eyes it's a behind-the-curve ORM based on the most basic ORM pattern available from Fowler's "Enterprise Application Architecture", and it seems most of the people _using_ AR never read it and have not thought at all about the tradeoffs vs. other ORM patterns (such as Data Mapper ; before anyone mentions the Ruby DataMapper ORM: That one doesn't actually implement the Data Mapper pattern). I particularly dislike the way it tends to result in code that is littered with leaky database abstractions where schema details tends to find its way into peoples controllers and views because it encourages people to call AR methods on model objects directly instead of even trying to encapsulate. Ruby is my favorite language, but Active Record is one of the things I hold greatly against Rails, not only for AR itself, but for the inspiration it provided to many other Ruby ORM's, that while they may improve on various aspects still to a large extent also end up encouraging leaking implementation details for your models all over the place. It'd be great if even 10% of the people using (and writing, it would seem, given that e.g. the Ruby ORM "Data Mapper" doesn't implement the Data Mapper pattern at all) these ORM's actually read the relevant chapters of EAA and pondered a bit on how it related to their applications.
- irahul 14y ago
  > Fowler's "Enterprise Application Architecture", and it seems most of the people _using_ AR never read it I wasn't aware Fowler is a required reading for anything(or I would say even beneficial) for _anything_, let alone AR. > I particularly dislike the way it tends to result in code that is littered with leaky database abstractions where schema details tends to find its way into peoples controllers and views Your whole rant doesn't have anything concrete I can respond to. How does schema details creep into controllers and views? > because it encourages people to call AR methods on model objects directly instead of even trying to encapsulate. Ummm. What? I don't understand. Are you proposing person.save is wrong and save should be abstracted? > Ruby is my favorite language, but Active Record is one of the things I hold greatly against Rails, not only for AR itself, but for the inspiration it provided to many other Ruby ORM's, that while they may improve on various aspects still to a large extent also end up encouraging leaking implementation details for your models all over the place. More rant. Still nothing concrete. AR maps the whole table, and if you are using AR, you should know that. If you need to map parts of the table, or compose parts from various tables as one object, use something else. Not every tool has to solve every problem.
  - vidarh 14y ago
    > I wasn't aware Fowler is a required reading for anything(or I would say even beneficial) for _anything_, let alone AR. Then I suggestion you read Enterprise Application Architecture. It's a great book for the way it formalises a number of very common patterns in a very concise way. It is also directly or indirectly the inspiration for a large number of recent ORM's and worth reading for that reason alone. Active Record the ORM is a direct implementation of Active Record the pattern as described in EAR for example. Unfortunately most picked off the easiest ORM pattern presented and stopped there, without alerting their users to all the caveats of the pattern. > Your whole rant doesn't have anything concrete I can respond to. How does schema details creep into controllers and views? Because the ORM spews methods all over the models that expose schema details whether or not they are relevant to the domain model. > Ummm. What? I don't understand. Are you proposing person.save is wrong and save should be abstracted? No, I am suggesting that, e.g. Person.where("some random SQL") is horrible. Yet it is hard enough to work with AR without resorting to crap like this, that you see stuff like that all over most code that uses AR. At least all the code I've looked at. > More rant. Still nothing concrete. AR maps the whole table, and if you are using AR, you should know that. If you need to map parts of the table, or compose parts from various tables as one object, use something else. Not every tool has to solve every problem. The problem is not what AR does, it is how it does it, and the way it's been packaged with Rails and given legitimacy that way despite being an exceedingly poor solution for anything but tiny projects because of a) the choice of the Active Record pattern, b) the poor level of abstraction. A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives.
    - irahul 14y ago
      > Unfortunately most picked off the easiest ORM pattern presented and stopped there, without alerting their users to all the caveats of the pattern. I have a general dislike for Fowler church of patterns. That is not to say I haven't gone through what is listed on his site. I didn't find it intriguing enough. I derive 100 times more value reading K&R than GoF. There is limited time and large number of books - one has to be picky. > No, I am suggesting that, e.g. Person.where("some random SQL") is horrible. Person.where("last_name = ?", last_name) is the most concise way to issue that query. Abstracting last_name so that if the field name changes, the query still is relevant is overkill. If you are so insistent, it isn't really hard to do a base model class which inherits from ActiveRecord::Base and do the mapper yourself. > exceedingly poor solution for anything but tiny projects github, twitter, heroku et al would like to disagree. Person.where("last_name = ?", last_name) makes it unsuitable for large projects? Personally, I have seen 1% cases where a migration changes column names, and when it does, re-factoring the code base for column name changes will take less than 2 minutes. > A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives. I don't understand. You are quoting it as if AR is the new kid on the block. It has been long enough to call it time tested. If Person.where("last_name = ?", last_name) is not abstract enough and makes it unsuitable for your projects(still the only concrete complaint from you), look for alternatives. I am not a fan of InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter and I would stick with Person.where("last_name = ?", last_name) and will fork AR if someone has a bright idea of adding layers of abstractions over a simple query.

vidarh 14y ago

I find it peculiar that anyone would describe ActiveRecord that way. In my eyes it's a behind-the-curve ORM based on the most basic ORM pattern available from Fowler's "Enterprise Application Architecture", and it seems most of the people _using_ AR never read it and have not thought at all about the tradeoffs vs. other ORM patterns (such as Data Mapper ; before anyone mentions the Ruby DataMapper ORM: That one doesn't actually implement the Data Mapper pattern). I particularly dislike the way it tends to result in code that is littered with leaky database abstractions where schema details tends to find its way into peoples controllers and views because it encourages people to call AR methods on model objects directly instead of even trying to encapsulate. Ruby is my favorite language, but Active Record is one of the things I hold greatly against Rails, not only for AR itself, but for the inspiration it provided to many other Ruby ORM's, that while they may improve on various aspects still to a large extent also end up encouraging leaking implementation details for your models all over the place. It'd be great if even 10% of the people using (and writing, it would seem, given that e.g. the Ruby ORM "Data Mapper" doesn't implement the Data Mapper pattern at all) these ORM's actually read the relevant chapters of EAA and pondered a bit on how it related to their applications.

irahul 14y ago
> Fowler's "Enterprise Application Architecture", and it seems most of the people _using_ AR never read it I wasn't aware Fowler is a required reading for anything(or I would say even beneficial) for _anything_, let alone AR. > I particularly dislike the way it tends to result in code that is littered with leaky database abstractions where schema details tends to find its way into peoples controllers and views Your whole rant doesn't have anything concrete I can respond to. How does schema details creep into controllers and views? > because it encourages people to call AR methods on model objects directly instead of even trying to encapsulate. Ummm. What? I don't understand. Are you proposing person.save is wrong and save should be abstracted? > Ruby is my favorite language, but Active Record is one of the things I hold greatly against Rails, not only for AR itself, but for the inspiration it provided to many other Ruby ORM's, that while they may improve on various aspects still to a large extent also end up encouraging leaking implementation details for your models all over the place. More rant. Still nothing concrete. AR maps the whole table, and if you are using AR, you should know that. If you need to map parts of the table, or compose parts from various tables as one object, use something else. Not every tool has to solve every problem.
- vidarh 14y ago
  > I wasn't aware Fowler is a required reading for anything(or I would say even beneficial) for _anything_, let alone AR. Then I suggestion you read Enterprise Application Architecture. It's a great book for the way it formalises a number of very common patterns in a very concise way. It is also directly or indirectly the inspiration for a large number of recent ORM's and worth reading for that reason alone. Active Record the ORM is a direct implementation of Active Record the pattern as described in EAR for example. Unfortunately most picked off the easiest ORM pattern presented and stopped there, without alerting their users to all the caveats of the pattern. > Your whole rant doesn't have anything concrete I can respond to. How does schema details creep into controllers and views? Because the ORM spews methods all over the models that expose schema details whether or not they are relevant to the domain model. > Ummm. What? I don't understand. Are you proposing person.save is wrong and save should be abstracted? No, I am suggesting that, e.g. Person.where("some random SQL") is horrible. Yet it is hard enough to work with AR without resorting to crap like this, that you see stuff like that all over most code that uses AR. At least all the code I've looked at. > More rant. Still nothing concrete. AR maps the whole table, and if you are using AR, you should know that. If you need to map parts of the table, or compose parts from various tables as one object, use something else. Not every tool has to solve every problem. The problem is not what AR does, it is how it does it, and the way it's been packaged with Rails and given legitimacy that way despite being an exceedingly poor solution for anything but tiny projects because of a) the choice of the Active Record pattern, b) the poor level of abstraction. A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives.
  - irahul 14y ago
    > Unfortunately most picked off the easiest ORM pattern presented and stopped there, without alerting their users to all the caveats of the pattern. I have a general dislike for Fowler church of patterns. That is not to say I haven't gone through what is listed on his site. I didn't find it intriguing enough. I derive 100 times more value reading K&R than GoF. There is limited time and large number of books - one has to be picky. > No, I am suggesting that, e.g. Person.where("some random SQL") is horrible. Person.where("last_name = ?", last_name) is the most concise way to issue that query. Abstracting last_name so that if the field name changes, the query still is relevant is overkill. If you are so insistent, it isn't really hard to do a base model class which inherits from ActiveRecord::Base and do the mapper yourself. > exceedingly poor solution for anything but tiny projects github, twitter, heroku et al would like to disagree. Person.where("last_name = ?", last_name) makes it unsuitable for large projects? Personally, I have seen 1% cases where a migration changes column names, and when it does, re-factoring the code base for column name changes will take less than 2 minutes. > A large chunk of developers are terribly excited about AR because it's better than what they're used to, and settle for it because it's part of Rails instead of looking for alternatives. I don't understand. You are quoting it as if AR is the new kid on the block. It has been long enough to call it time tested. If Person.where("last_name = ?", last_name) is not abstract enough and makes it unsuitable for your projects(still the only concrete complaint from you), look for alternatives. I am not a fan of InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonPainter and I would stick with Person.where("last_name = ?", last_name) and will fork AR if someone has a bright idea of adding layers of abstractions over a simple query.