Windows Form Controls e LINQ; Che cosa dovrei tornare?

Question

Quando si lavora con i controlli Windows Form e LINQ c'è un "migliore opzione" per il modo in cui il livello di Buisiness restituisce i dati?

In questo momento sto tornando DataTable in modo che possa quindi impostare il DataSource al DataTable restituito. C'è una soluzione migliore? Perché?

public class BLLMatrix
{
    public static DataTable GetMaintItems(int iCat)
    {
        IQueryable<tblCaseNotesMaintItem> tItems = DALMatrix.GetCNTable();
        return
            (tItems.Where(item => item.CategoryID == iCat & item.IsActive).OrderBy(item => item.OrderID).Select(
                item => new { item.ItemID, item.ItemDescription })).CopyLinqToDataTable();
    }

internal static class DALMatrix
{
    internal static MatrixDataContext MatrixDataContext = new MatrixDataContext();

    internal static Table<tblCaseNotesMaintItem> GetCNTable()
    {
        return MatrixDataContext.GetTable<tblCaseNotesMaintItem>();
    }

---

Ho trovato questo simile domanda -> Separare le preoccupazioni con LINQ to SQL e DTO

Answer 1

Personalmente, preferisco oggetti di trasferimento dati, ma DataSet lavoro in un pizzico.

In sostanza, l'idea è che se si lavora con oggetti di trasferimento dati (che non hanno la logica, e rappresentano il modello che si sta cercando di lavorare con il cliente), che è un'astrazione che può vivere indipendentemente dalle modifiche sulla parte anteriore o posteriore. E 'in genere una buona idea.

DataSet sono utili, ma la loro mancanza di sicurezza in fase di compilazione (non nel caso di DataSet fortemente tipizzato però) a causa della / accesso campo stringa a base numerica può rappresentare un problema.

In genere, v'è anche una grande quantità di overhead in serializzare DataSet su un filo rispetto ad un oggetto di trasferimento dei dati.

Answer 2

Mi piace creare le mie classi del modello a causa del sovraccarico di dataset. Se si restituisce una matrice di oggetti (o qualsiasi cosa che implementa l'interfaccia IList) si può ancora impostare la parità per la proprietà DataSource della maggior parte degli elementi di ASP.NET.

Answer 3

mi piace personalmente a impostare il mio DataSources quando si utilizzano i collegamenti per List<YourObject>

Answer 4

Io preferisco business logic per restituire un'istanza di un oggetto, come auto, Icar o List (automobile) Lasciate che il DAL popolano l'oggetto per voi. In questo modo si mantiene una netta separazione tra dati e interfaccia utente.

Answer 5

Mi piace usare DataReader invece di set di dati, e userò un blocco iteratore nello strato di dati di trasformare il DataReader in un IEnumerable<IDataRecord>. Da lì, ho una sorta di passo in più tra il business e lo strato di dati di tradurre che IEnumerable in un IEnumerable<MyBusinessObject>. Dovreste essere in grado di passare questo al livello di presentazione per associazione dati pure.

Mi piace questo approccio perché fa un lavoro migliore che separa gli strati di dati e di business: lo strato di business non deve pensare in termini di set di dati, e lo strato di dati non dovrebbe aver bisogno di sapere come costruire oggetti di business. Se penso a questo come un livello separato ottengo il meglio dei due mondi. Una modifica i sia i dati aziendali o livelli significa ho solo bisogno di modificare il codice di fabbrica per che costruisce i miei oggetti di business.