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 4:42

>>27
Yeah, it would take some work. You would need to write the rules for generating the efficient queries you are looking for. You would need to be able to specify what fields you are actually interested in getting and things like that to take advantage of that loading the index optimization mentioned earlier. But it can be done with some computer algebra. Make an engine with some rules for substitution and a heuristic for what forms would perform better, then do a heuristic search for a more optimal equivalent form. These expressions can usually be evaluated at compile time, so you can put time into it.

You could even adjust the backend to look for different forms in each backend implementation.

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