Your method is removing a collection of entities that exist in some set.
When I see Remove
, I'd say it removes a single item from something. Now if that collection actually existed in the set, then it would be perfect, but alas it's a collection of items to remove.
One thing to consider, assuming you're making an extension method for the EF5 DbSet
, it already has a Remove
method that removes a single item, I think an overload to remove more items doesn't sound like a bad idea to me.
On the other hand, LINQ to XML defines a Remove()
method on enumerables of XNode
. But that's an extension on the collection of entities, not the parent set. I'm a little on the fence on this one.
RemoveMany
, while better as it indicates we're removing many items, doesn't fit well with me. It mimics SelectMany
by name but I'd associate the "Many" part with a projection, certainly not with a remove operation. I'd avoid that one.
I might consider ExceptEntities
to be similar to the LINQ method Except
. Except
returns the set difference of two collections where the result contains unique values. Since this operation isn't quite the same, we'll still need to make this distinguishable hence the added "Entities". Since you are dealing with a set (?), this sounds perfect to me. But after thinking about this more, I'm not quite sure this is the better option since this modifies the collection.
I think RemoveEntities
might be a better fit. "Remove" makes it sound as though we're modifying something. RemoveAll
doesn't cut it for me as it is named the same as List.RemoveAll
which removes all that matches a predicate. There's also a List.RemoveRange
which removes a range of consecutive values in the collection, not quite the same.
So I'd go with RemoveEntities
but an overload of the Remove
name might be fine, just beware of the similarities of the names in other objects.