En una aplicación web que me he encontrado, he encontrado el siguiente código para hacer frente a la DataContext cuando se trata de LinqToSqlLinqToSql DataContext estática en una aplicación web
public partial class DbDataContext
{
public static DbDataContext DB
{
get
{
if (HttpContext.Current.Items["DB"] == null)
HttpContext.Current.Items["DB"] = new DbDataContext();
return (DbDataContext)HttpContext.Current.Items["DB"];
}
}
}
Entonces referencia a ella más adelante haciendo esto:
DbDataContext.DB.Accounts.Single(a => a.accountId == accountId).guid = newGuid;
DbDataContext.DB.SubmitChanges();
He estado investigando las mejores prácticas cuando se trata de LinqToSQL.
No estoy seguro del enfoque que ha tomado este cuando se trata de que DataContext no sea ThreadSafe y se mantenga una copia estática de ello.
¿Es este un buen enfoque para tomar en una aplicación web?
@ Longhorn213 - De acuerdo con lo que dices y cuanto más he leído en HttpContext por eso, creo que tienes razón. Pero en la aplicación que he heredado, esto es confuso porque al comienzo de cada método se está volviendo a consultar el db para obtener la información, luego se modifica esa instancia del contexto de datos y se envían los cambios en él.
A partir de esto, creo que debe desaconsejarse este método porque da la falsa impresión de que el contexto de datos es estático y persiste entre las solicitudes. Si un futuro desarrollador piensa que volver a consultar los datos al principio de un método porque cree que ya está allí, podría tener problemas y no entender por qué.
Supongo que mi pregunta es, ¿debería desaconsejarse este método en futuros desarrollos?
Aquí hay una gran publicación con más detalles: http://blog.stevensanderson.com/2007/11/29/linq-to-sql-the-multi-tier-story/ –
Acabamos de lanzar una variante de este concepto esta noche. –