Where the logic hides in rails apps

In the Obvious architecture, it would be something more like..

    class CreateContact
      def initialize contact_jack, email_jack
        @contact_jack = contact_jack
        @email_jack = email_jack
      end
    
      def do input
        # validate input
        
        contact = Contact.new
        contact.populate input

        contact_jack.save contact.to_hash

        email = ContactEmail.new
        email.populate contact.to_hash

        email_jack.send email.to_hash

        contact.to_hash
      end
    end

With that structure you can call CreateContact with:

    action = CreateContact.new
    result = action.do ContactJack.new, EmailJack.new

In that structure you can totally test the action and logic without hitting the db or the mail system at all. Your ContactJack and EmailJack can be easily swapped out for various pluggable data stores. Fileystem, MySQL, Mongo, Postgres, Cassandra, could be swapped out for the ContactJack. EmailJack could send through standard mail servers, SendGrid, Amazon AWS, Mandrill, etc.

Obvious is on github, you can read more at http://obvious.retromocha.com

Hey, I'm not the OP, but I have some thoughts based on my experience creating the Obvious Architecture.

1) Hiding persistance from the programmer by tying it to your models is a bad idea. It's where a lot of problems start. First, how do you test without hitting the database? How long do your tests take? Minutes? Hours? Or do you skip them?

I don't think your models should do persistance at all. They should model your data for you. Do validation against your business rules. That sort of thing.

Would you tie your models to the filesystem? If not, then why would you tie them to the database?

Pulling your persistance mechanism out of your models is the first step to writing fast, maintainable, highly testable code, even if you are still using rails.

2) Rails conventions want you to tie your DB to your objects, which is a bad idea. Rails does a lot of things well, like it gives you a nice structure for controllers, views, routing, asset management, so use it for those things. Rails is a delivery mechanism. Use it as one and leave data modeling and persistance to something else.

3) I think the name issue could be solved by treating it as "action" object. Think of actions as more like actors. They do things. They integrate models/entities and persistance mechanisms along with minor amounts of logic that don't fit inside of entities.

As an action object, you could all it CreateContact and it would be called create_contact.rb in the app/actions folder. Then, when you look in the app/actions folder, the file name communicates what it does - it creates a contact.

4) Actually, it helps a lot with testing. Creating a new class makes dependency injection super easy, making testing super easy and fast. Also, it can help with clarity and glance factor. Imagine you have an app/actions folder with files like create_contact.rb, remove_contact.rb, send_email.rb, get_contact.rb, compose_email.rb and so on. You look at that folder and you can see that it is probably an contact management and email app. Maybe an contact or newsletter management app?

That kind of glance factor you can't get with a bunch of higher level controller or service containers. It also avoids the problem of "what controller/module/service does this method belong to?"

5) I actually agree that the code that the OP did was not the best in that the persistence and email sending mechanisms aren't passed in to the action, so that you don't know what it is going to try and save and where. If the code explicitly passed in the persistence and email mechanisms it would be more apparent that an email is going to be sent as part of the CreateContact action. That being said, I would probably make those two separate actions for clarity's sake.

I've written some apps using the Obvious Architecture and it really does help solve a lot of the problems that default Rails MVC creates.

A class that has a name that's not a noun should always be suspect, imo.