Windows-Formular-Steuerelemente und LINQ; Was soll ich wiederkommen?

Question

Bei der Arbeit mit Windows Form-Steuerelemente und LINQ ist es eine „beste Option“, wie Sie Ihre Buisiness Schicht gibt die Daten?

Im Moment ist mir Rückkehr Tables, so dass ich dann die Datasource zu der zurückgegebenen Datentabelle einstellen. Gibt es eine bessere Option? Warum?

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

---

Ich fand diese ähnliche Frage -> Trennung Anliegen mit Linq To SQL und DTO

Answer 1

Ich persönlich ziehe Datenübertragung Objekte, aber Datasets arbeiten in eine Prise.

Im Grunde ist die Idee, dass, wenn Sie mit Data Transfer Objects arbeiten (die keine Logik haben, und stellen das Modell, das Sie suchen, mit auf dem Client arbeiten), dass eine Abstraktion ist, die unabhängig von Veränderungen leben kann auf der Vorder- oder Rückseite Ende. Es ist in der Regel eine gute Idee.

Datasets sind nützlich, aber ihr Mangel an Kompilierung-Sicherheit (nicht im Falle von stark typisierte Datasets obwohl) wegen numerischen / string-basierten Feldzugriff kann ein Problem darstellen.

Normalerweise gibt es auch eine große Menge an Overhead in Dataset über einen Draht im Vergleich zu einem Data Transfer Object Serialisierung.

Answer 2

Ich mag meine eigene Modellklassen zu schaffen, weil der Aufwand für Datasets. Wenn Sie ein Objekt-Array (oder irgendetwas, die IList-Schnittstelle implementiert) kehren Sie immer noch, dass gleich die Datasource-Eigenschaft der meisten ASP.NET-Elemente festlegen.

Answer 3

Ich persönlich mag meine Datasources setzen, wenn Links mit List<YourObject>

Answer 4

Ich ziehe die Business Logic eine Instanz eines Objekts, wie Auto, ICAR oder List (Car) zurückzukehren Lassen Sie die DAL das Objekt für Sie füllen. So können Sie pflegen eine klare Trennung zwischen Daten und UI.

Answer 5

Ich mag Datareader verwenden, anstatt Datensätze, und ich werde einen Iteratorblock in der Datenschicht verwenden, um die Datareader in eine IEnumerable<IDataRecord> einzuschalten. Von dort habe ich eine Art zusätzlichen Schritt zwischen dem Unternehmen und Datenschicht, dass IEnumerable in ein IEnumerable<MyBusinessObject> zu übersetzen. Sie sollten dies auch auf die Präsentationsschicht hindurchgeführt werden können für Datenbindung.

Ich mag diesen Ansatz, weil es einen besseren Job macht, die Daten und Business-Schichten zu trennen: die Business-Schicht nicht in Bezug auf den Datensätze denken soll, und die Datenschicht soll nicht müssen wissen, wie Business-Objekte zu konstruieren. Wenn ich das als eine separate Ebene denke, habe ich das Beste aus beiden Welten. Eine Änderung der entweder die Daten oder Geschäftsebenen bedeutet, ich muss nur den Werkscode ändern zu, dass meine Business-Objekte konstruiert.