1. #1
    dieterm's Avatar
    Registered
    27/02/04
    Location
    Zemst
    Posts
    197
    iTrader
    3 (100%)
    Mentioned
    0 Post(s)
    Reputation
    0/0

    [.NET] LINQ/Entity Framework/Sync Framework of iets anders?

    Hallo allemaal,

    Ik zit met enkele vragen ivm een Database/Webservice probleem.
    Ik ben momenteel aan een programma aan het werken (MagentoXtender) dat de mogelijkheid zou moeten bieden om producten in te voeren in een Magento Webshop database via een XMLRPC webservice.
    De eerste stap die ik al gemaakt heb is de webservice functies vertaald in VB.NET. Voor de XMLRPC kant maak ik gebruik van de class library vanop XML-RPC.Net .

    De volgende stap is om gegevens (productgegevens, productcategorieën, producttypes, bestellinggegevens, klantengegevens, etc...) uit een MS SQL Server 2005 database te halen en deze via de webservice 'synchroniseren' met de webshop database. In een nog latere fase zou het moeten mogelijk worden om gegevens van eender welke databron (XML, Oracle, Mysql, andere MagentoWebservice, Excellijst,...) te kunnen gebruiken om de Webshop database te vullen met data.
    Een extra moeilijkheid is misschien het gegeven dat de webshop database gebruik maakt van een EAV (entity/attribute/value) model. Dus ik ken niet op voorhand alle properties van mijn objecten.

    Het idee is dus om een "theoretisch database model' op te stellen, en dit dan vervolgens voor elke soort van databron te implementeren. Voor elke tabel zou ik moeten kunnen de Create/Read/Update/Delete functies kunnen zelf implementeren, Queries kunnen vertalen naar de databron-speciefieke technologie, Metadata bijhouden van alle objecten (om rijen van de ene databron te kunnen matchen met rijen in de andere databron),...

    Nu komt natuurlijk mijn vraag: Wat is de beste aanpak om zoiets te maken?

    Ik heb al wat research gedaan en ben voor het .NET framework volgende dingen tegengekomen die mij op het eerste zicht ideaal lijken:
    • Microsoft ADO.NET Entity Framework
    • Microsoft Sync Framework
    • Linq


    Zelf heb ik al enkele jaren (eigen) ervaring met VB.NET, maar de drie dingen die ik hierboven heb opgesomd zijn nog nieuw, en ik ben er nog niet mee vertrouwd.

    Is iemand van jullie al vertrouwd met een van deze drie nieuwe technologieën in de context van het synchroniseren van data tussen twee totaal verschillende databasetypen/structuren?

    Zijn er alternatieven op de markt (voor .NET) die nodige features hebben voor mijn probleem?

    Het zijn misschien veel vragen, maar ik zou graag een idee krijgen of hetgeen ik van plan ben haalbaar is en binnen welke realistische tijd.

    Alvast bedankt voor jullie reacties.
    no votes  

  2. #2

    Registered
    08/11/03
    Location
    Antwerpen
    Posts
    1,726
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    2/2
    Quote Originally Posted by dieterm View Post
    This quote is hidden because you are ignoring this member. Show
    Nu komt natuurlijk mijn vraag: Wat is de beste aanpak om zoiets te maken?

    Ik heb al wat research gedaan en ben voor het .NET framework volgende dingen tegengekomen die mij op het eerste zicht ideaal lijken:
    • Microsoft ADO.NET Entity Framework
    • Microsoft Sync Framework
    • Linq


    Zelf heb ik al enkele jaren (eigen) ervaring met VB.NET, maar de drie dingen die ik hierboven heb opgesomd zijn nog nieuw, en ik ben er nog niet mee vertrouwd.

    Is iemand van jullie al vertrouwd met een van deze drie nieuwe technologieën in de context van het synchroniseren van data tussen twee totaal verschillende databasetypen/structuren?

    Zijn er alternatieven op de markt (voor .NET) die nodige features hebben voor mijn probleem?

    Het zijn misschien veel vragen, maar ik zou graag een idee krijgen of hetgeen ik van plan ben haalbaar is en binnen welke realistische tijd.

    Alvast bedankt voor jullie reacties.
    Even een verduidelijking van de technologieën die je hierboven opnoemd:

    - het entity framework is een OR mapping implementatie van Microsoft. Momenteel is er enkel nog maar support voor SQL Server databases. Oracle, MySQL etc is nog bezig met hun provider.

    - het sync framework is iets wat nuttig kan zijn voor occasionally connected systems (bijvoorbeeld outlook). Je werkt dan met een lokale database (SQL Server Compact), die je synchroniseert met de main database wanneer je netwerktoegang hebt.

    - linq is een querytaal om verschillende datasources op een gelijkaardige manier te queryen (linq to sql, link to entities, linq to xml, link to flikr, ...). Linq To SQL is zo goed als dood btw. Linq to Entities is om het entity framework te queryen.
    no votes  

  3. #3
    dieterm's Avatar
    Registered
    27/02/04
    Location
    Zemst
    Posts
    197
    iTrader
    3 (100%)
    Mentioned
    0 Post(s)
    Reputation
    0/0
    Is het in de nieuwste versie van het entity framework niet mogelijk om je eigen "DataContext" te bouwen?

    Dus een klasse die eigenlijk de database voorstelt, maar waar ik mijn eingen Insert Update Delete Select commando's implementeer.

    Het probleem is dat ik nergens een voorbeeld vindt hierover.
    no votes  

  4. #4
    dieterm's Avatar
    Registered
    27/02/04
    Location
    Zemst
    Posts
    197
    iTrader
    3 (100%)
    Mentioned
    0 Post(s)
    Reputation
    0/0
    Wat ik niet goed snap is hoe LINQ to Entity en ADO.NET Entity Framework verband houden met elkaar?

    Dit is hoe ik het momenteel begrijp:
    Het ADO.NET Entity Framework is bedoelt voor het mappen van een theoretisch Classendiagramma naar een concrete database die de nodige ADO.NET Providers gedefinieerd heeft (zoals voor MS SQL Server).

    LINQ To Entities is om de SQL-achtige queries van LINQ te kunnen gebruiken om een lijst met eigen gemaakte objecten te kunnen queryen.

    Wat ik dus zou willen doen is LINQ kunnen gebruiken (niet alleen de select, maar ook de insert, update, delete commando's van LINQ) om de data van mijn databron te kunnen opvragen/wijzigen.

    Ik zou dus een abstracte klasse (of interface, weet niet welke het beste is) willen defineren met een aantal properties die elke concrete databron moet definieren, bijvoorbeeld:
    Code:
    Public MustInherit Class Product
        'deze EntityID, dewelke voor elke entity (product, category, klant,..) zou moeten geimplementeerd worden,
        ' zou ik dan gebruiken om via het Sync Framework producten van twee 
        'verschillende datasources te kunnen synchroniseren met elkaar
        Property EntityID As SyncId     
    
        Property Name As String
        Property Price As Decimal
    End Class
    Vervolgens maak ik dan een abstracte klasse die de Database voorstelt:
    Code:
    Public MustInherit Class AbstractDatabase
        Inherits Global.System.Data.Objects.ObjectContext 
        'is dit de juiste classe om van over te erven voor LINQ een database voor te stellen?
    
         ReadOnly Property Producten As Data.Objects.ObjectQuery(Of Product)
         'Ik weet niet of ik dit een juiste klasse is om de producten voor te stellen. 
         'Is het mss beter om hier een IQueryable(Of Product) type van te maken?
    
    End Class
    Verder zou ik de LINQ Queries willen kunnen omzetten naar een XmlRpcStruct (wat niet meer is dan een serialisable Dictionary(Of String, Object)) omdat ik dat dan als argument aan mijn webservice kan meegeven, zodat ik niet telkens alle producten moet ophalen, maar enkel degenen die voldoen aan de filterexpressie in die XmlRpcStruct. Als ik het goed heb wordt een LINQ Query voorgesteld door een ExpressionTree. Klopt het dan wanneer ik zeg dat ik die ExpressionTree moet opvangen, en zelf omzetten naar zo'n xmlrpcstruct?
    no votes  

  5. #5
    Duke_Puke's Avatar
    Registered
    10/04/03
    Location
    Ieper
    Posts
    253
    iTrader
    7 (100%)
    Mentioned
    0 Post(s)
    Reputation
    0/0
    Als het louter om ORM gaat, kun je misschien ook even kijken of nHibernate niks voor je kan doen...
    -empty-
    no votes  

  6. #6
    Moto's Avatar
    Registered
    17/07/02
    Location
    Wilrijk
    Posts
    1,994
    iTrader
    2 (100%)
    Mentioned
    0 Post(s)
    Reputation
    9/16
    Kan niet volledig volgen, maar ge kunt natuurlijk altijd een Custom LINQ provider schrijven
    no votes  

  7. #7

    Registered
    08/11/03
    Location
    Antwerpen
    Posts
    1,726
    iTrader
    0
    Mentioned
    0 Post(s)
    Reputation
    2/2
    Quote Originally Posted by dieterm View Post
    This quote is hidden because you are ignoring this member. Show
    Wat ik niet goed snap is hoe LINQ to Entity en ADO.NET Entity Framework verband houden met elkaar?

    Dit is hoe ik het momenteel begrijp:
    Het ADO.NET Entity Framework is bedoelt voor het mappen van een theoretisch Classendiagramma naar een concrete database die de nodige ADO.NET Providers gedefinieerd heeft (zoals voor MS SQL Server).

    LINQ To Entities is om de SQL-achtige queries van LINQ te kunnen gebruiken om een lijst met eigen gemaakte objecten te kunnen queryen.

    Wat ik dus zou willen doen is LINQ kunnen gebruiken (niet alleen de select, maar ook de insert, update, delete commando's van LINQ) om de data van mijn databron te kunnen opvragen/wijzigen.

    ADO.NET Entity Framework is een OR mapping framework. Je genereert op basis van je database klassen die je kan aanpassen zodat ze niet 1 op 1 hoeven te zijn met de database zijn. Die klassestructuur bestaat uit drie delen en wordt opgeslagen in een xml bestand.

    LINQ To Entities is de taal om het je Entity Model te queryen, dus het class model dat jij hebt gemaakt op basis van je database. Het entity framework zorgt voor de mapping van je classmodel naar je database model.

    Als je iets wil inserten mbv het je entity model, maak je gewoon een nieuwe instantie aan van de class die je gedefinieerd hebt in je class diagram. Vervolgens wijst je ze toe aan de correcte context en roep je de save aan van je context ofzo. Om te deleten markeer je je instantie gewoon als deleted en roep je weer de save van je context op. De gegenereerd classes uit je entity model implementeren het unit of work pattern om hun changes te tracken denk ik.

    Ik denk dat het zo ongeveer werkt. Zeker ben ik niet want ik heb er ook nog niet mee gewerkt .
    no votes  

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in