Objectify: A Better Way to Build Rails Applications

You'll have to decide if he made his case or not, but if that's what he thinks then better he just come right out with it instead of dancing around.

Note that he did not call James ridiculous, he criticized the idea. Which is how it should go (if there's going to be criticism).

You can debate whether his assertion is justified, but some (many, perhaps) ideas really are fucking ridiculous and it's better to just cut to the chase.

Anyway, the whole discussion so far was about dealing with the problem of large (in terms of code size) models, so I assumed by "scalability" you mean scalability in terms of being able to handle very large code bases, not performance issues. I do not understand how the approach presented here would result in performance improvements? I've commented elsewhere on the problems associated with it, others did as well in a fairly convincing way I think. I do not deny that problems with scaling both in the performance sense and in the code size sense do exist, I just do not see how Objectify solves any of them and I do see how many problems it introduces.

As for breaking your app down into separate HTTP services, I agree this can be useful in some situations, but it is completely different from the approach outlined in Objectify, for one you still get a chance to do (almost) normal OO modelling and structure the code in a reasonable way, even if the message passing is done via HTTP and not simply via Ruby method calls.

http://en.wikipedia.org/wiki/Dataflow_programming

Parts of this approach might be valuable, as I tried to emphasize, but as a whole this doesn't look good for plenty of reasons mentioned in the thread.

This is the dependency injection part, not the policy/service/responder core of the framework I am talking about.

There don't have to be. The classes and instances are being referred to by the developer in the same way as any first-class functions defined elsewhere would be - they're actually resolved and called by the framework.

I am not talking about what happens on the level of Ruby, I am talking about what happens logically at the level of the framework. The classes represent functions, sure, but they do not call other functions (services/policies/responders), the only "function-calling" is done by the router. Yes, this too is a form of functional programming, the form known as dataflow programming where the flow of the data is described explicitly.

It certainly is OO. There are instances, and they receive and act on messages. Yes, there's a dataflow-like DSL for routing, but that's not to the exclusion of other paradigms.

It isn't OO at the level of the framework. Yes, Ruby is underneath, there are classes, there are instances, and the thin ORM layer is object oriented, but the objects within the framework do not exchange messages, the only object doing all the message dispatch is the router. This is not OO, just look at the traits listed here: http://en.wikipedia.org/wiki/Object-oriented_programming

The framework basically forces you to abandon messaging (since there is no exchange of messages, just single directional messages flow from the router), abandon encapsulation (since the services have to access the data of the domain objects and hence the domain objects must make their data available to everyone) and abandon polymorphism (since the services are statically dispatched by the router). How can this be object oriented?

If it was a framework modelled in an object oriented way it would itself be built of classes exchanging messages, but it isn't. It encourages you to also structure your code in a non object oriented way by creating hundreds of little services which are basically procedure calls instead of making your model accept a wider variety of messages or instead of building classes with more than just a "call" method. Most of the code is supposed to go directly into the services, that's the whole point of the framework, remember it is a solution to the "fat model" problem:

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”.

Also, keep in mind that the services do not normally call each other (they could in theory, but that would be even more awkward), so instead of having message exchange between models you have duplicated code in services or have to use inheritance. Ruby is object oriented so sure there are message calls further down, it doesn't make the framework object oriented on the logical level.

Only if you're conflating domain objects with persistence objects.

Must you go as far as to refer to a hypothetical reality just to win an argument ;) ? That's how Rails works, that's what the examples show, I am not referring to what is possible in theory, but to what the framework does and the most reasonable possible way of using it. Honestly one more level of indirection would make this look completely ridiculous.

They're statically dispatched on a constant name, not on a class. If you need polymorphism at that point, it's trivial to define a dynamic service resolver - all you need is something with a #new method assigned to the constant to do whatever late binding you want.

Ehm, no? You cannot just define a "new" method returning whatever you want neither in a module nor in a class in Ruby. You would have to overwrite the initialization methods that are usually hidden from the user. Passing a constant name is almost equivalent to passing a class.

  module Foo
    def new
      5
    end
  end

  puts Foo.new.inspect
  # undefined method `new' for Foo:Module (NoMethodError)

  class Bar
    def new
      5
    end
  end

  puts Bar.new.inspect
  # #