none
LINQ - individueller select RRS feed

  • Frage

  • Hallo

    ist es bei LINQ-Abfragen möglich, in der "select"-bedingung auch eigene individuelle Spalten und Werte einzufügen, wie ich es zum Beispiel aus einer SQL-Anweisung kenne

    SELECT xTable.*,
         False AS indivColumn01,
         'hello' AS indivColumn02,
         10 AS indivColumn03
    FROM xTable
    WHERE xTable.PrimaryKey = .....
    ORDER BY .....
    

    wenn Ja - kann mir dabei bitte jemand weiterhelfen ?

    Danke & schönen Gruß

    Michael

    Mittwoch, 1. September 2010 06:49

Antworten

Alle Antworten

  • Hallo Michael,

    zum Beispiel über Projektion (etwa mit: "select new") ist hier eines der gängigen Verfahren.

    [Vorgehensweise: Formulieren von Projektionen (LINQ to SQL)]
    http://msdn.microsoft.com/de-de/library/bb386978.aspx

    Auch "Entity SQL" ist eine Möglichkeit:

    [ObjectQuery(T)-Konstruktor (String, ObjectContext) (System.Data.Objects)]
    http://msdn.microsoft.com/de-de/library/bb738995.aspx

    Man sollte ggf. prüfen (u.a. Intellitrace), wie das SQL umgesetzt wird (je nach EF Version ggf. unterschiedlich).


    ciao Frank

    • Als Antwort markiert M.Erlinger Mittwoch, 1. September 2010 10:19
    Mittwoch, 1. September 2010 08:21
  • Hallo Michael,

    in LINQ kannst Du generell ein neue Klassen Instanz erstellen,
    entweder von einem bekannten Typ oder anonym, siehe
    Datentransformationen mit LINQ (C#)
    (dort insbes.  Auswählen einer Teilmenge jedes Quellelement )

    Verwendest Du

    var query = from t in xTable
      // where
      // orderby
      select new { xTable.Spalte1,
        t.Spalte2,
        indivColumn01 = False,
        indivColumn02 = 10 };
    
    so erhältst Du einen anonymen Typ   - dessen Verwendbarkeit eingeschränkt ist.

    Handelt sich bei xTable um eine DataTable und Du willst es wie eine DataTable
    weiterbehandeln, benötigst Du eine  DataTable, die die zusätzlichen Spalten einführt.
    Denn eine DataRow kann nur im Kontext einer DataTable existieren,
    da für jede Spalte eine DataColumn erforderlich ist.
    In den Fällen ist es einfacher die DataColumn mit entsprechendem Typ hinzuzufügen.
    Mehr siehe Beispiele für die Abfrageausdruckssyntax: Projektion (LINQ to DataSet)

    Bei Abfragen auf Klassen wie im Entity Framework wären zusätzliche
    Eigenschaften denkbar, die man die dort an die partiellen Klassen anfügen kann.
    siehe Erweitern der vom Entity Framework generierten Typen (Entity Framework)

    Gruß Elmar

     

    • Als Antwort markiert M.Erlinger Mittwoch, 1. September 2010 10:19
    Mittwoch, 1. September 2010 08:26
    Beantworter
  • Hallo Elmar,

           > Handelt sich bei xTable um eine DataTable und Du willst es wie eine DataTable
           > weiterbehandeln, benötigst Du eine  DataTable, die die zusätzlichen Spalten einführt.

    nur ergänzend ... es würde in einem solchen Fall nicht unbedingt ein DataTable notwendig sein, das kommt etwas auf das "Szenario" an. Die DataRow kann hier auch selber projiziert werden und die Projektion benötigt dann ggf. keinen DataTable. Solche Methoden können u.a. in Silverlight Services Anwendung finden.


    ciao Frank
    Mittwoch, 1. September 2010 08:41
  • Danke Euch für die rasche Rückmeldung und Hilfe!!

    Schönen Gruß - Michael

    Mittwoch, 1. September 2010 10:20
  • Hallo Michael,

    Noch etwas. Der einzige mir z.Z. bekannte Weg, um das *ganze* SELECT-Statement *serverseitig* bearbeiten zu lassen (das ist z.B. wichtig wenn Du in den Alias-Spalten T-SQL-Funktionen verwendest, die über keine Erweiterungsmethoden abgedeckt werden), bleibt DataContext.ExecuteQuery:

    var query = context.ExecuteQuery<Customers>("SELECT CustomerID, CompanyName, ContactName, 'LDXHK-0' As Code FROM Customers WHERE City = 'London'");
    

    Dies erzeugt folgendes SQL-Statement:

    SELECT CustomerID, CompanyName, ContactName, 'LDXHK-0' As Code FROM Customers WHERE City = 'London'
    

    Wenn Du hingegen schreibst:

    var query1 = from c in Customers
    where c.City == "London"
    select new {CompanyName = c.CompanyName, ContactName = c.ContactName, Code = "LDXHK-0"} ; 
    
    

    ehältst Du als SQL-Statement nur:

    -- Region Parameters
    DECLARE @p0 NVarChar(6) SET @p0 = 'London'
    -- EndRegion
    SELECT [t0].[CompanyName], [t0].[ContactName]
    FROM [Customers] AS [t0]
    WHERE [t0].[City] = @p0
    

    Die "individuellen Spalten" werden hier erst lokal "angehängt".

    DataContext.ExecuteQuery steht im Konflikt mit dem Sinn von LINQ, aber als ein Tool unter vielen anderen leistet es manchmal unverzichtbare Dienste.

    Gruß
    Marcel

    Mittwoch, 1. September 2010 11:33
    Moderator