Le migliori pratiche riguardano:LINQ To SQL per l'accesso ai dati

Question

Parte dell'applicazione web su cui sto lavorando è un'area che mostra i messaggi dalla direzione a 1...n utenti.Ho un progetto DataAccess che contiene le classi LINQ to SQL e un progetto di sito Web che rappresenta l'interfaccia utente.Il mio database è simile a questo:

Utente -> MessageDetail <- Messaggio <- MessageCategory

MessageDetail è una tabella di join che contiene anche un flag IsRead.

L'elenco dei messaggi è raggruppato per categoria.Ho due controlli ListView nidificati sulla pagina: uno restituisce il nome del gruppo, mentre un secondo nidificato all'interno è associato a MessageDetails e restituisce i messaggi stessi.Nel code-behind della pagina che elenca i messaggi ho il seguente codice:

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;
}

Questo codice lavori, ma inserire un'enorme istruzione LINQ come questa nel code-behind per un controllo LinqDataSource semplicemente non mi va bene.

Sembra che io stia ancora codificando le query nell'interfaccia utente, solo che ora è LINQ invece di SQL.Tuttavia, ritengo che la creazione di un altro livello tra le classi L2S e l'interfaccia utente ridurrebbe parte della flessibilità di LINQ.Il punto non è ridurre la quantità di codice che scrivi per recuperare i dati?

Esiste una possibile via di mezzo che non vedo o sto solo fraintendendo il modo in cui dovrebbe essere utilizzato LINQ to SQL?Il consiglio sarebbe molto apprezzato.

Answer 1

Tutte le query LINQ dovrebbero essere in a classe di logica aziendale, nessun cambiamento rispetto alle metodologie precedenti come ADO.

Se sei un purista dovresti sempre restituire List(of T) dai tuoi metodi nella business class, infatti, il datacontext dovrebbe essere visibile solo alle classi business.Quindi puoi manipolare l'elenco nell'interfaccia utente.

Se sei un pragmatico, puoi restituire un oggetto IQueryable ed effettuare alcune manipolazioni nell'interfaccia utente.

Answer 2

Indipendentemente da LINQ, penso che mescolare il codice di presentazione con il codice correlato al database non sia una buona idea.Vorrei creare un semplice livello di astrazione DB sopra le query LINQ.A mio avviso LINQ è semplicemente uno strumento conveniente, che non ha un impatto serio sulla progettazione delle applicazioni tradizionali.