Windows Form Controls und LINQ; Was soll ich zurückgeben?

Question

Wenn Sie mit Windows Form-Steuerelementen und LINQ arbeiten, gibt es eine "Beste Option" für die Art und Weise, wie Ihr Unternehmenslayer die Daten zurückgibt?

Momentan gebe ich DataTables zurück, damit ich die DataSource dann auf die zurückgegebene DataTable setzen kann. 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 ->Separating concerns with Linq To SQL and DTO's

Answer 1

Ich persönlich ziehe Transfer Objects Daten, aber Datasets in eine Prise zu arbeiten.

Grundsätzlich ist die Idee, dass, wenn Sie mit Datenübertragungsobjekten arbeiten (die keine Logik haben und das Modell darstellen, mit dem Sie auf dem Client arbeiten möchten), eine Abstraktion ist, von der unabhängig davon leben kann Änderungen am vorderen oder hinteren Ende. Es ist normalerweise eine gute Idee.

DataSets sind nützlich, aber ihr Mangel an Kompilierzeitsicherheit (nicht im Fall von stark typisierten DataSets) wegen numerischen/string-basierten Feldzugriffs kann ein Problem darstellen.

In der Regel gibt es auch einen hohen Aufwand beim Serialisieren von DataSets im Vergleich zu einem Datenübertragungsobjekt.

Answer 2

Ich möchte meine eigenen Modellklassen wegen des Overhead von DataSets erstellen. Wenn Sie ein Objektarray (oder ein Objekt, das die IList-Schnittstelle implementiert) zurückgeben, können Sie dies immer noch der DataSource-Eigenschaft der meisten ASP.NET-Elemente zuordnen.

Answer 3

ich persönlich meine Datasource gerne setzen, wenn Links zu List<YourObject>

Answer 4

Ich ziehe die Business-Logik mit einer Instanz eines Objekts zurück, wie Auto, ICAR oder List (Car) der DAL für das Objekt füllen lassen Sie. Auf diese Weise erhalten Sie eine klare Trennung zwischen Daten und UI.

Answer 5

Ich möchte lieber DataReaders als Datasets verwenden, und ich verwende einen Iterator-Block in der Datenebene, um den Datenreader in eine IEnumerable<IDataRecord> zu verwandeln. Von dort aus habe ich eine Art zusätzlichen Schritt zwischen der Geschäfts- und der Datenschicht, um IEnumerable in eine IEnumerable<MyBusinessObject> zu übersetzen. Sie sollten dies auch für die Datenbindung an die Präsentationsebene weitergeben können.

Ich mag diesen Ansatz, weil er die Daten- und Business-Schichten besser trennt: Die Business-Schicht sollte nicht in Form von Datensätzen denken, und die Datenschicht sollte nicht wissen müssen, wie sie Business-Objekte erstellen. Wenn ich das als eine separate Stufe betrachte, bekomme ich das Beste aus beiden Welten. Eine Änderung der Daten oder der Geschäftsstufen bedeutet, dass ich nur den Werkscode für das Konstrukt ändern muss, in dem meine Geschäftsobjekte erstellt werden.