Mejores prácticas con respecto a:LINQ To SQL para acceso a datos

Question

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

Usuario -> Detalle del mensaje <- Mensaje <- Categoría del mensaje

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 genera el nombre del grupo, mientras que el segundo anidado en el interior está vinculado a MessageDetails y genera los mensajes 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 codigo obras, pero incluir una declaración LINQ enorme como esta en el código subyacente de un control LinqDataSource simplemente no me sienta bien.

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

¿Hay algún posible término medio que no veo, o simplemente estoy entendiendo mal la forma en que se supone que se usa LINQ to SQL?Se agradecería mucho el consejo.

Answer 1

Todas sus consultas LINQ deben estar en un clase de lógica de negocios, no hay cambios con respecto a metodologías más antiguas como ADO.

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

si eres un pragmatista, puede devolver un objeto IQueryable y realizar algunas manipulaciones en la interfaz de usuario.

Answer 2

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