Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

ORM patterns

Name: Anonymous 2013-08-09 13:02

If there's one reason to pick FIOC over Ruby, it's the ORMs that exist for each language. It's 2013 and Ruby doesn't have a single Data Mapper implementation. Even the gem named "DataMapper" is actually an Active Record impl. Everything in Ruby is AR all the way down.

AR is a terrible way to approach persistence. It forces you to tie your domain logic to database code. It makes unit testing close to impossible (no, Rails faggots, you're not doing unit testing with your sqlite db). When you open up a class file, you don't even know what the hell the attributes are, because they'll all be implicitly derived from the database. There's no domain model with AR. You can't even require your fucking classes in a shell because of all the database tie ins.

What's puzzling is that Ruby is so well suited for a good Data Mapper ORM. And the way Ruby handles OO is so appropriate for a pure Domain Model architecture. Ruby has all the tools, but nobody's doing it. Why? Why don't people use simple PORO classes for models and business logic and abstract all the persistence bullshit to a DM implementation? I don't get it.

My theory is that Ruby developers are just ex-PHP developers who think they're awesome for not using PHP anymore. They try to hide their backgrounds, but that's the truth. They've never touched a large Java app so they have no idea that besides their flaws, Java apps can be very maintainable at high complexity thanks to frameworks such as Hibernate.

FIOC has SQLAlchemy, a decent Data Mapper implementation which of course doesn't force you to fucking inherit from something else and lets you write good, easy to test FIOC code.

Name: Anonymous 2013-08-10 6:15

>>32
Hi, you must be new here.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List