SqlFunctions and SqlSpatialFunctions classes offer the possibility of using SQL Server specific functions in LINQ queries. They are similar to DbFunctions/EntityFunctions classes but the later allow access to canonical/provider independent functions.
When we moved the code of the SQL Server EF provider into its own assembly we just forgot to move these classes out of EntityFramework.dll.
We should look into what is the most appropriate namespace for these classes in a similar way in which we should look into what we do about DbFunctions/EntityFunctions (see issue [832](http://entityframework.codeplex.com/workitem/832)).
Regarding the namespace, when it makes sense we are trying to consistently leave old APIs under System.Data.Entity.Core. However, in this particular case I propose these classes directly into the System.Data.Entity because:
1. Once you add a reference to the SQL Server provider you don't need any additional namespaces to take advantage of the functionality in these classes.
2. The old namespace, System.Data.Objects.SqlClient wasn't a very useful choice, and would translate into System.Data.Entity.Core.Objects.SqlClient which makes this functionality extremely undiscoverable.
3. It doesn't look like we need to change the name at all: in this case Sql is used as a prefix indicating SQL Server in a similar way in which it is used in other provider specific classes, like SqlConnection, SqlCommand, etc. We actually recommend provider writers that they offer their own provider specific functions following a similar pattern.
When we moved the code of the SQL Server EF provider into its own assembly we just forgot to move these classes out of EntityFramework.dll.
We should look into what is the most appropriate namespace for these classes in a similar way in which we should look into what we do about DbFunctions/EntityFunctions (see issue [832](http://entityframework.codeplex.com/workitem/832)).
Regarding the namespace, when it makes sense we are trying to consistently leave old APIs under System.Data.Entity.Core. However, in this particular case I propose these classes directly into the System.Data.Entity because:
1. Once you add a reference to the SQL Server provider you don't need any additional namespaces to take advantage of the functionality in these classes.
2. The old namespace, System.Data.Objects.SqlClient wasn't a very useful choice, and would translate into System.Data.Entity.Core.Objects.SqlClient which makes this functionality extremely undiscoverable.
3. It doesn't look like we need to change the name at all: in this case Sql is used as a prefix indicating SQL Server in a similar way in which it is used in other provider specific classes, like SqlConnection, SqlCommand, etc. We actually recommend provider writers that they offer their own provider specific functions following a similar pattern.