We have a few extension method sponsor classes named after the interfaces most of the extension methods target, e.g. IQueryableExtensions, IDbSetExtensions.
The argument has been made that for consistency we should avoid the 'I' prefix for anything that is not an interface in a .NET library.
I propose an alternative naming convention which consists on forming the name of the extension method sponsor class by concatenating the 'Extensions' suffix after the name of the main type targeted at runtime (as opposed to the type used in the signature of the 'this' argument of the extension method), e.g.:
* IQueryableExtensions --> DbQueryExtensions
* IDbSetExtensions --> DbSetExtensions
While the methods will also work with other implementations of the interfaces, e.g. some of the extension methods work for any IQueryable<T> that also implements IDbAsyncEnumerable<T>, those at runtime are really either real DbQuery instances, fake versions of DbQuery or instances of our legacy query type ObjectQuery<T>.
The argument has been made that for consistency we should avoid the 'I' prefix for anything that is not an interface in a .NET library.
I propose an alternative naming convention which consists on forming the name of the extension method sponsor class by concatenating the 'Extensions' suffix after the name of the main type targeted at runtime (as opposed to the type used in the signature of the 'this' argument of the extension method), e.g.:
* IQueryableExtensions --> DbQueryExtensions
* IDbSetExtensions --> DbSetExtensions
While the methods will also work with other implementations of the interfaces, e.g. some of the extension methods work for any IQueryable<T> that also implements IDbAsyncEnumerable<T>, those at runtime are really either real DbQuery instances, fake versions of DbQuery or instances of our legacy query type ObjectQuery<T>.