Skip to content

Instantly share code, notes, and snippets.

@bobbytables
Created November 27, 2012 00:24
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save bobbytables/4151585 to your computer and use it in GitHub Desktop.
Save bobbytables/4151585 to your computer and use it in GitHub Desktop.
Repository Pattern questions

Attempting to find a good way to give a wrapper around AR objects to give them Repository pattern effects.

  • Do validations stay on the ActiveRecord model or do they move to the Repository object?

  • Is delegating attributes / errors / finders to the AR object bad?

    For example: UserRepository.new.errors => Calls user.errors ?

  • When calling associations (User => Comments), does the Repository return CommentRepository objects, or Comment objects?

  • Are we giving the view a repository object, or a ValueObject, which could be a decorator / presenter object since they're immutable.

@steveklabnik
Copy link

AR and repositories are fundamentally different, trying to use it this way is just gonna lead to pain.

@bobbytables
Copy link
Author

So wrapping them is a no go in your opinion? I've seen comments around the place that creating a wrapper around AR is a possibility.

@bloudermilk
Copy link

At a high level I agree with @steveklabnik that the Active Record pattern and Repository pattern are two fundamentally opposing patterns, but to address your questions:

Do validations stay on the ActiveRecord model or do they move to the Repository object?

They belong on the domain layer / model.

Is delegating attributes / errors / finders to the AR object bad?

The first two should only ever exist on the domain objects. I'm not sure what you mean by "finders", but if it has anything to do with querying the data store, then yes it's bad.

For example: UserRepository.new.errors => Calls user.errors ?

UserRepository.new should yield an instance of some repository object that is configured with an adapter to some data mapper. You'd use the repository to CRUD domain objects, but the repository would never itself act as a facade to your model. In terms of implementation, the repository pattern looks nothing like the decorator pattern, which you seem to be relating it to. In AR terms, the repository is much closer to the DB connection/adapter than instances of your AR model.

When calling associations (User => Comments), does the Repository return CommentRepository objects, or Comment objects?

See above. Your domain objects should know nothing about your repository (or persistence in general), so the repository would be responsible for fetching and assigning relations. I have some ideas for this that I'll likely be writing up in a wishlist README soon.

Are we giving the view a repository object, or a ValueObject, which could be a decorator / presenter object since they're immutable.

See above. Specifically, though, your repository shouldn't know about your decorator/presenter. Two entirely difference concerns there.

Finally, take all the above with a huge grain of salt, as I've never used the repository pattern in production and all my knowledge of it is based on light reading...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment