Are commands/write operations in a repository an anti-pattern?

I've used the Repository Pattern in a few .NET projects now, but I always get back to arguing with myself about this question:

Thinking of a repository as a queryable data store, one could argue that having commands (or write operations) in a repository is a misconception, as to the command-query separation principle. On the other hand, keeping the methods that have to do with the same domain objects in the same class simplifies coding and usage, and promotes the DRY and KISS principles.

Which different views/arguments开发者_运维百科 do you have? What would Fowler or Evans say?

For me, having persistence logic & references to underlying technologies like O/RMs in one place is more important than splitting by the read/write responsibility. So I combine command & queries in one concrete repository per domain aggregate root, usually with a persistence-technology specific abstract base class (Nhibernate, Entity Framework, etc).

The only time I split these up is when I am doing a complete CQRS implementation (command/query responsibility segregation) with event sourcing, i.e., when reading and writing happens in completely different areas of my code base against different data stores.