First we have the false modularity. You see a bunch of separate stuff (classes, methods, whatever) and think "Wow, nice, now we can reuse this all over the place!" The truth is that these policies/services/renderers are going to be complected; you're going to create them in triplets as you implement your application. Moving things around doesn't make them modular. They can only be modular if the author actually implements them in a modular way (and you can do that in Rails today).

The DI-framework can't handle change at all:

    class CurrentUserResolver
      def initialize(user_finder = User)
        @user_finder = user_finder
      end

      # note that resolvers themselves get injected
      def call(session)
        @user_finder.find_by_id(session[:current_user_id])
      end
    end

And then there's the added complexity. Now I need to keep track of the route-mapping, default policy, route policies, the route service and the route renderer. Which are now in several different files. And there's not even a clean class-to-file mapping to help me locate it.

Oh, and the premise of testability. Well, this makes it very easy to test units itself, but the more you split your projects into smaller units, the more bugs occur when you mix the units. Sure, you can get your precious fast test runs (and a nice green test), but in reality you're only testing a single unit of a complected app.

EDIT: This reminds my of Rick Hickey's quote from keynote at RailsConf2012:

""We can make the same exact software we are making today with dramatically simpler stuff—dramatically simpler languages, tools, techniques, approaches. Like really radically simpler—radically simpler than Ruby which seems simple.""

Having said this, I respect the attempt, the problem it tries to solve certainly does exist to some extent, and the solution cannot be completely dismissed very easily.

But please, please, do learn both A) basic history and B) basic theory of the field you are working in. If you try to reinvent everything you decrease your chances of contributing something new manyfold.

I don't think there is a single right answer that is applicable in all cases. But over time, I've come to believe that as a default, code works well when it resembles how you'd ideally explain the service to an extremely intelligent, non-technical person with domain experience. This makes for code that is easy to understand, collaborate around, and modify given changing objectives.

That means creating "Policy" and especially "Service" models--extra nouns--very sparingly. For example, an Elevator was once a nounification of a verb, but people understood it, so it makes sense as a class. ElevatorDoor's good too, but ElevatorDoorOpeningService is probably not good. This is absolutely at odds with strict application of the Single Responsibility Principle.

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.

What is wrong with writing your core application logic physically removed from any of these frameworks. Why do people insist on fitting their application into the Rails framework or any other web framework.

Write your core application code in Ruby (or your language of choice), package it in another gem, use tools and patterns we've had all along to plug that code into a dependency for persistence (if needed)...communicate with it through a standard API that you define for your delivery mechanism (i.e. Rails).

I just don't get this idea of trying to contain my application code within the confines of a specific framework.

Wrong. I'm hearing this more and more, but let's be clear: Active Record as a design pattern, before Rails, has always been a joining of business logic and persistence. (http://martinfowler.com/eaaCatalog/activeRecord.html) It's always been in violation of the single responsibility principle. If you want to avoid that, don't use Active Record! Use a Data Mapper, which specifically separates Mappers and Finders from Domain model classes. (http://martinfowler.com/eaaCatalog/dataMapper.html)

I'm not saying you can't move logic out into reusable modules or whatever is being recommended here, but please don't make it out like people are in the wrong when they're using the library or framework the way it was designed to be used.

He echoed the phrase I've seen elsewhere "Ruby just doesn't need that".

I disagreed with him then, and still do. People like to claim that OOP breeds cargo cult programming and overly cumbersome abstractions upon abstractions (and it can), but some times you really do need that kind of approach to make a large scale project testable and maintainable.

I'm glad to see there are Ruby devs who can see the value in using these kind of approaches. I honestly believe it's the kind of thing you think is a major waste of time, until you are shown the benefit first hand, and you experience the change. Then you start to understand that by spending a significant deal of time up front building your infrastructure, you can save a lot of time down the road.

I know that's how it was for me years back.

I personally think that writing reusable libraries using Decorator/Presenter patterns or Modules with ActiveSupport::Concern is simple approach.

Avdi's slides: https://speakerdeck.com/u/avdi/p/making-little-classes-out-o...

I highly recommend Objects on Rails book: http://objectsonrails.com/

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

Update: not saying that's a bad thing I used to be a Flex developer and all the frameworks used MVCS (Robotlegs being my favorite). Controllers are all commands and Services are used to retrieve data.

Emphasis mine. I don't think this has to be true. Yes, models get fatter, but the responsibilities will have to be implemented somewhere and to me it's simpler and easier to debug when it's as close to the domain model as possible instead of in some abstract/generic model.

Of course, if you have policies and services that apply across domains, then by all means break them out and recompose as necessary in the the models

Sounds nice, would be fine with it as a default, but not sure it warrants doing a big change for me.

The vast majority of people who scale Rails sites (as far as I can tell) do so by breaking their apps into services. ActiveRecord god-objects do not make that step in an app's life cycle easy, and separating persistence from business models is likely to be your first important step when refactoring for scalability. Fragmenting a User model bloated beyond all hope of sanity is almost a rite of passage at this point.

I often think the only Rails developer who hasn't found ActiveRecord bloat to be an irritation and an obstacle to scaling is DHH, and although that makes his opinion on the subject even more valuable than it would normally be, he doesn't talk about it enough in my opinion. Pretty much everyone else, as far as I can tell, responds to Rails scaling issues by creating services in Sinatra and/or divorcing business modeling from persistence logic.

I want someone to challenge my prejudicial assumption here, most of all because I appear to be saying "Rails can't scale," which is BS, but also because I'm very tempted not to take this discussion seriously at all if it doesn't address this point. It's just the crucial point in my opinion. I like the whole OOP thing but to me the decision to use something like Objectify is all about scalability. That doesn't just mean performance; it also means retaining readability when you have a lot of code. Single Responsibility Principle makes code readable.

- Splitting out logical pieces of behaviour into separate modules, especially the ones less central to the core responsibilities of the class. If you look at Rails itself (it's great Ruby code, I highly recommend really reading it), this is the way it is structured, ActiveRecord::Base provides tons of functionality as a single class, yet it still is very neatly laid out into many well-separated modules. See e. g.:

https://gist.github.com/1014971

http://api.rubyonrails.org/classes/ActiveSupport/Concern.htm...

https://github.com/jakehow/concerned_with

http://blog.waxman.me/extending-your-models-in-rails-3

Deciding what things would fit well into external modules and what modules to create is a new skill to be learned, but I think it can work well once you do learn it.

- Things that aren't part of business logic but just handle some more technical matters should be extracted into plugins and not be directly part of the models (for example: special kinds of validations).

- There is the whole world of OO techniques and patterns that can be applied here just like anywhere else. For example you can extract complicated algorithms into separate classes or use value objects:

http://api.rubyonrails.org/classes/ActiveRecord/Aggregations...

I don't think the problem people seem to have with Objectify is that they see it as a totally invalid solution to a problem--and I agree with your assessment that many people see this problem as very real.

My own take is that I find it disingenuous to call it an Object-Oriented solution to the problem; it's not. That doesn't make it bad, invalid, or wrong. It rightly raises a few eyebrows to talk about effectively calling namespaced procedures as if it were the pinnacle of Object-oriented design.