While a parameterless constructor which automatically finds a connection seems like a good idea, it tightly couples the object context to the configuration file.
It also introduces some "magic" in that the consumer has no clear way to determine how to change the connection string associated with the parameterless constructor (except to read the source).
I guess my answer is, regardless of whether the Entity Framework allows you to do this, you probably shouldn't. Use a factory instead, and achieve the same flexibility without tying the object context to the configuration system:
public interface ICustomDataContextFactory
{
CustomDataContext Create();
}
public class CustomDataContextFactory : ICustomDataContextFactory
{
private readonly string _connectionStringName;
public CustomDataContextFactory(string connectionStringName)
{
_connectionStringName = connectionStringName;
}
public CustomDataContext Create()
{
var connectionString = ConfigurationManager.ConnectionStrings[_connectionStringName].ConnectionString;
return new CustomDataContext(connectionString);
}
}
This provides all consumers the same mechanism for creating a parameterless instance, while allowing implementors to decide how the instance is created - perhaps a different connection string needs to be used for a particular instance, or the database name is read from the command line on startup.
I realize that you said you don't want to introduce a new class which passes the connection string through. I took that to mean a class derived from CustomDataContext
and not a factory, which is a new concept here.
(This answer only really applies to production code. The parameterless constructor trick is useful in ephemeral code like proofs-of-concept.)