Objectify: A Better Way to Build Rails Applications
jamesgolick.com
Objectify: A Better Way to Build Rails Applications
1–10 of 72 posts
Re: Objectify: A Better Way to Build Rails Applications
#2FWIW there's already a library called Objectify that's a Java-based ORM (lite) for AppEngine:
http://code.google.com/p/objectify-appengine/
If you want your project to be found easily (on search engines) I always suggest:
1. Prefer a made up word to a non-English word (or a word in any live language for that matter); and
2. Don't choose a name that something else in the same or similar space shares. They've been around longer. It's just going to make your life harder.
YMMV.
Re: Objectify: A Better Way to Build Rails Applications
#3>One in particular is something I've been thinking about and
>refining for a while now [3]. In this approach, persistence
>objects remain extremely thin, and business logic is
>encapsulated in lots of very simple objects known as
>“services” and “policies”. Not all objects in this
>methodology will fit in to one of those two categories,
>but they are two of the most important concepts.
I've seen this division of labor outlined in this DestroyAllSoftware screencast : https://www.destroyallsoftware.com/screencasts/catalog/fast-...
As can be implied by the title, one of the side effects of keeping your service logic in their own separate plain Ruby classes is that you don't have to load Rails as dependency which means tests can run _really_ fast.
Re: Objectify: A Better Way to Build Rails Applications
#4>One in particular is something I've been thinking about and >refining for a while now [3]. In this approach, persistence >objects remain extremely thin, and business logic is >encapsulated in lots of very simple objects known as >“services” and “policies”. Not all objects in this >methodology will fit in to one of those two categories, >but they are two of the most important concepts. I've seen this division of labo…
Yeah, services are one of the types that have leaked out of DDD (and probably leaked into it from somewhere else).
Re: Objectify: A Better Way to Build Rails Applications
#5I don't get why these models get bloated. If there's a language that makes it east break up classes into any number of components, surely that's Ruby! Mixins, open classes, modules, etc..
Re: Objectify: A Better Way to Build Rails Applications
#6I don't get why these models get bloated. If there's a language that makes it east break up classes into any number of components, surely that's Ruby! Mixins, open classes, modules, etc..
Mixins/modules and open classes do not separate your class in to multiple components - merely multiple files. As I explain in the article, for separate components to be useful, they have to be "protected" from each other - encapsulation, in other words.
Re: Objectify: A Better Way to Build Rails Applications
#7Can't say I'm a fan of single-method classes. They always make me ask "why isn't this just a method?"
Re: Objectify: A Better Way to Build Rails Applications
#8Can't say I'm a fan of single-method classes. They always make me ask "why isn't this just a method?"
Because of SRP.
Re: Objectify: A Better Way to Build Rails Applications
#9Can't say I'm a fan of single-method classes. They always make me ask "why isn't this just a method?"
Because of SRP.
At first I thought this was an attempt at trolling, but then I noticed that Mr. Golick is the commenter so therefor I must assume serious intent.
Care to give an answer better than "some book some java dudes wrote 20 years ago said so"?
While I generally agree with SRP, when that single responsibility can be expressed in a single function, I don't see the win with have a class dedicated to it. Smells of pedant OO nonsense.
Is not instantiation etc a cross-cutting concern that violates SRP in this instance?
Re: Objectify: A Better Way to Build Rails Applications
#10Does this actually perform faster by being on top of rails or would we need a new Ruby framework to get the most speed optimizations from the services and policies?