asp.net - net - web forms c# tutorial

Mejores prácticas re: LINQ a SQL para acceso a datos

Question

Parte de la aplicación web en la que estoy trabajando es un área que muestra los mensajes de la administración a 1 ... n usuarios. Tengo un proyecto de DataAccess que contiene las clases de LINQ a SQL y un proyecto de sitio web que es la IU. Mi base de datos se ve así:

Usuario -> MessageDetail <- Message <- MessageCategory

MessageDetail es una tabla de unión que también contiene un indicador IsRead.

La lista de mensajes está agrupada por categoría. Tengo dos controles ListView anidados en la página: uno emite el nombre del grupo, mientras que el otro anidado dentro está vinculado a MessageDetails y emite los mensajes ellos mismos. En el código subyacente de la página que enumera los mensajes, tengo el siguiente código:

protected void MessageListDataSource_Selecting(object sender, LinqDataSourceSelectEventArgs e)
{
var db = new DataContext();
// parse the input strings from the web form
int categoryIDFilter;
DateTime dateFilter;
string catFilterString = MessagesCategoryFilter.SelectedValue;
string dateFilterString = MessagesDateFilter.SelectedValue;
// TryParse will return default values if parsing is unsuccessful (i.e. if "all" is selected"):
// DateTime.MinValue for dates, 0 for int
DateTime.TryParse(dateFilterString, out dateFilter);
Int32.TryParse(catFilterString, out categoryIDFilter);
bool showRead = MessagesReadFilter.Checked;
var messages =
from detail in db.MessageDetails
where detail.UserID == (int)Session["UserID"]
where detail.Message.IsPublished
where detail.Message.MessageCategoryID == categoryIDFilter || (categoryIDFilter == 0)
where dateFilter == detail.Message.PublishDate.Value.Date || (dateFilter == DateTime.MinValue)
// is unread, showRead filter is on, or message was marked read today
where detail.IsRead == false || showRead || detail.ReadDate.Value.Date == DateTime.Today
orderby detail.Message.PublishDate descending
group detail by detail.Message.MessageCategory into categories
orderby categories.Key.Name
select new
{
MessageCategory = categories.Key,
MessageDetails = categories.Select(d => d)
};
e.Result = messages;
}

Este código funciona , pero pegar una gran declaración LINQ como esta en el código subyacente para un control LinqDataSource simplemente no me sienta bien.

Parece que todavía estoy codificando consultas en la interfaz de usuario, solo que ahora es LINQ en lugar de SQL. Sin embargo, creo que construir otra capa entre las clases L2S y la UI reduciría parte de la flexibilidad de LINQ. ¿No es el objetivo de reducir la cantidad de código que escribes para obtener datos?

¿Hay algún punto medio posible que no estoy viendo, o simplemente estoy malinterpretando la forma en que se supone que se usará LINQ to SQL? El consejo sería muy apreciado.

Answer 1

Independientemente de LINQ, creo que mezclar el código de presentación con el código de base de datos no es una buena idea. Crearía una capa simple de abstracción de base de datos además de consultas LINQ. En mi opinión LINQ es solo una herramienta conveniente, que no tiene un impacto serio en el diseño de aplicaciones tradicionales.

Answer 2

Todas sus consultas de LINQ deben estar en una clase de lógica de negocios , sin cambios de metodologías anteriores como ADO.

Si eres un purista , siempre deberías devolver la Lista (de T) de tus métodos en la clase de negocios, de hecho, el contexto de datos solo debería ser visible para las clases de negocios. Luego puede manipular la lista en la interfaz de usuario.

Si es un pragmático , puede devolver un objeto IQueryable y realizar algunas manipulaciones en la interfaz de usuario.