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