C'est similaire à l'approche utilisée par @Glazed ci-dessus, mais mon approche consiste également à utiliser une classe DbContext personnalisée, mais je fais l'inverse. Au lieu de modifier le modèle T4 (fichier .tt sous votre .edmx), j'hérite en fait de la classe MyEntities résultante, comme suit :
Classe MyEntities générée par le modèle T4 :
public partial class MyEntities : DbContext
{
public MyEntities()
: base("name=MyConnectionStringName")
{
}
...
}
Créez ensuite une nouvelle classe personnalisée pour envelopper MyEntities comme suit :
public class MyEntitiesContainer : MyEntities
{
private static readonly int _DEFAULT_TIMEOUT = 100;
public MyEntitiesContainer()
{
((IObjectContextAdapter)this).ObjectContext.CommandTimeout = _DEFAULT_TIMEOUT;
}
//Use this method to temporarily override the default timeout
public void SetCommandTimeout(int commandTimeout)
{
((IObjectContextAdapter)this).ObjectContext.CommandTimeout = commandTimeout;
}
//Use this method to reset the timeout back to default
public void ResetCommandTimeout()
{
((IObjectContextAdapter)this).ObjectContext.CommandTimeout = _COMMAND_TIMEOUT;
}
}
Dans votre code, instanciez la classe Container et si vous devez utiliser un délai d'attente personnalisé pour une commande spécifique, définissez-le manuellement à l'aide des méthodes fournies.
using (var db = new MyEntitiesContainer()) {
db.SetCommandTimeout(300);
db.DoSomeLongCommand();
db.ResetCommandTimeout();
db.DoShorterCommand1();
db.DoShorterCommand2();
...
}
L'avantage de cette approche est que vous pouvez également créer une interface pour votre classe Container et utiliser des instances de l'interface avec l'injection de dépendances, vous pouvez alors simuler votre base de données dans vos tests unitaires en plus d'avoir un contrôle plus facile sur le délai de commande et d'autres propriétés du contexte objet pour lesquelles vous pouvez créer des méthodes (comme le chargement paresseux, etc.).