3 ms·

DRY is the #1 reason I use an ORM. I also think that it's a factor that is rarely if ever considered by people who choose not to use an ORM.

spacemanmatt 12y ago
DRY is the reason I write a remote facade. Security (e.g. sanitizing inputs) is less-repeated at the database boundary than at myriad application/ORM implementations.
- crdoconnor 12y ago
  >DRY is the reason I write a remote facade. Remote facade sounds like a lot of boilerplate to me.
  - spacemanmatt 12y ago
    It truly varies. If all you're doing is sanitizing a simple INSERT, it's almost pure boilerplate, but that is not a very interesting or common case. I'll offer some of the reasoning that got me to building remote facades. The database needed to sanitize its own inputs; we could not trust application developers with that. There would be multiple client-languages (Ruby, Python, Java, for starters) and I wanted to keep domain adapters for those languages simple as possible. The database would be changing regularly, and many changes could be simply absorbed in the remote facade, so applications depending on the remote facade via their client-language libraries would be somewhat insulated. Now, it wasn't a perfect regime, and nothing is. But it paid the bills for years and my schemas are still in play at that place.
rosser 12y ago
Your database is just about the worst place in the world to be strict about DRY. It turns out, your model and validations don't actually prevent broken data. They just make you think you're safe from it... ...until your broken data starts biting you and your customers in places that don't typically see sunlight.
- crdoconnor 12y ago
  >Your database is just about the worst place in the world to be strict about DRY. There are no places in any code base at all where it doesn't pay to be rigorous about DRY. >It turns out, your model and validations don't actually prevent broken data. A) DRY isn't about preventing broken data. B) Validations are for preventing broken data. That's what they do.

spacemanmatt 12y ago

DRY is the reason I write a remote facade. Security (e.g. sanitizing inputs) is less-repeated at the database boundary than at myriad application/ORM implementations.

crdoconnor 12y ago
>DRY is the reason I write a remote facade. Remote facade sounds like a lot of boilerplate to me.
- spacemanmatt 12y ago
  It truly varies. If all you're doing is sanitizing a simple INSERT, it's almost pure boilerplate, but that is not a very interesting or common case. I'll offer some of the reasoning that got me to building remote facades. The database needed to sanitize its own inputs; we could not trust application developers with that. There would be multiple client-languages (Ruby, Python, Java, for starters) and I wanted to keep domain adapters for those languages simple as possible. The database would be changing regularly, and many changes could be simply absorbed in the remote facade, so applications depending on the remote facade via their client-language libraries would be somewhat insulated. Now, it wasn't a perfect regime, and nothing is. But it paid the bills for years and my schemas are still in play at that place.

rosser 12y ago

Your database is just about the worst place in the world to be strict about DRY. It turns out, your model and validations don't actually prevent broken data. They just make you think you're safe from it... ...until your broken data starts biting you and your customers in places that don't typically see sunlight.

crdoconnor 12y ago
>Your database is just about the worst place in the world to be strict about DRY. There are no places in any code base at all where it doesn't pay to be rigorous about DRY. >It turns out, your model and validations don't actually prevent broken data. A) DRY isn't about preventing broken data. B) Validations are for preventing broken data. That's what they do.