Page 1 of 2 1 2 LastLast
Results 1 to 15 of 27

Thread: ORM - Wel of geen dataset gebruiken voor koppeling aan GUI

  1. #1

    ORM - Wel of geen dataset gebruiken voor koppeling aan GUI

    Hallo hallo,

    Sinds een tijdje gebruik ik een ORM (kbmmw) en dat bevalt me uitstekend, alleen vraag ik me af hoe ik een "gewoon object" (<> TDataset) van het ORM, bijvoorbeeld een TPersoon het best kan koppelen aan de GUI. Ik zie bij andere ORM frameworks, bijvoorbeeld entity dac van Devart, dat er vaak toch nog een dataset wordt gebruikt om de koppeling naar de GUI te maken. Nu heeft het gebruik van een dataset wel bepaalde voordelen, zoals het automatisch updaten van controls op basis van de state. En dat je bijvoorbeeld een edit kunt cancelen en zelfs eenvoudig een undo kunt inbouwen. Ik kan natuurlijk al deze functionaliteit wel weer zelf gaan bouwen, maar dan eindig ik waarschijnlijk weer met een soort dataset.

    Wat is wijsheid? Wel of geen dataset tussen form en een "gewoon object".

  2. #2
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Ik denk dat het helemaal ligt aan welke componenten je gebruikt.
    mORMot en TiOPF gebruiken gewone GUI compnenten en hebben een framework gebouwd waarmee een simulatie wordt uitgevoerd van DBcomponenten. D.m.v. van dat framework worden gegevens van jouw object opgeslagen in de database. Livebindings doet het eigenlijk op dezelfde manier. EntityDAC lijkt een TDataset te hebben.
    Maar zij hebben het framework zo gemaakt, dat het object communiceert met hun eigen tdataset, die op een bepaalde manier kan communiceren met een datasource, waardoor je 'velden' hebt en deze kan koppelen aan een GUI DBcomponent.

    Zo heb ik het ervaren.
    Delphi is great. Lazarus is more powerfull

  3. #3
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Ik twijfel ook vaak.
    Dataset koppelt "lekker" aan grids / dbcontrols.
    Maar datasets hebben (in mijn ogen) ook nadelen: het verplichte edit+post mechanisme, het feit dat de dataset niet compleet kan zijn (niet alle records opgehaald), en het bestaan van een "recordpointer" maakt de toegang ala list/array niet goed mogelijk.
    Wijsheden welkom hier :-)

  4. #4
    het verplichte edit+post mechanisme
    Wordt een post bij jou direct weggeschreven in de DB?

    Ik ga TiOPF even bekijken!

  5. #5
    Heb even een op youtube een howto bekeken over TiOPF, maar dat wat ik zo snel zie is dat niet echt een hele aantrekkelijke oplossing.

  6. #6
    volgens mij is dit een van de dingen die Kim in zijn framework gaat oplossen met de smartbindings.

    Zelf gebruik ik het ORM nog niet, dus mijn ei nog niet gelegd. In het verleden wel dingen gebouwd die geen dataset gebruikten in de schermen, maar dat was gewoon handwerk om de edit's en andere controls te koppelen aan de data die erachter lag.

    Blijft denk ik een uitdaging in vcl zonder de standaard dbaware-->datasource-->dataset.

  7. #7
    Ja, in de laatste release zit smartbindings (beta) en het is inderdaad super makkelijk om van alles en nog wat (controls, datasets, custom objecten, objectlists) aan elkaar te binden op een overzichtelijke manier. Zeker de moeite waard om naar te kijken.

    Sinds een tijdje ben ik overgestapt van de traditionele query en custom services op smartservices i.c.m. het ORM en dat werkt echt heel makkelijk, krijg je er praktisch een gratis REST server bij . Ik krijg van mijn services gewone objecten terug (geen datasets) Dus in principe kan alles zonder datasets regelen, alleen zit ik dan met wat losse eindjes.
    Bij datasets en data-aware controls wordt de state automatisch voor je geregeld en ook kun je gebruik maken van ingebouwde undo functies (versioning in kbmMemTable). Nu kan ik er redelijk makkelijk een dataset tussen hangen, maar ik vroeg me af of er andere manieren waren.

    Wat ik op youtube zag over TiOPF lijkt niet echt optie. Wat ik zag was omslachtig en er stond naar mijn mening teveel in de forms zelf. Ook bouw je dan weer een extra afhankelijkheid in en daar zit ik niet op te wachten.

  8. #8
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Wordt een post bij jou direct weggeschreven in de DB?
    Het liefst wel. Het liefst zou ik zelfs iedere veldverandering het direct de database inschrijven, maar dat kan natuurlijk lang niet altijd.
    Maar ik heb ook een programma onder mijn hoede met cashed updates + transactions etc. Altijd gezeur haha :-)

  9. #9
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Ik denk dat wij veel te ouderwets over denken. In FM heb je geen keus. Daar MOET je livebindings gebruiken om data te presenteren. Eigenlijk wil je ook geen dataset op je smartphone.
    Het gebruik van ORM is best wel oud, maar te weinig ondersteund in deze community. Ik kan mij nog wel herinneren over een discussie met het gebruik van BO jaren geleden.

    Ik ben nog steeds een poging aan het doen om te doorgronden hoe TIOPF en mORMot werken. Zelf heb ik iets gemaakt wat volgens mij de beginselen van dei twee frameworks zijn. Maar het is best veel werk. Maar als de basis er ligt, zal het makkelijker moeten gaan.
    Attached Files Attached Files
    Last edited by jkuiper; 14-May-19 at 13:02.
    Delphi is great. Lazarus is more powerfull

  10. #10
    Quote Originally Posted by jkuiper View Post
    Maar het is best veel werk. Maar als de basis er ligt, zal het makkelijker moeten gaan.
    Im my humble (not so much I guess... ) opinion all current solutions until now have required much too much boilerplate code to do something.
    The moment the plumbing takes significant focus away from the business features, then its bad. I personally hate writing plumbing code for the end user apps I make.

    kbmMW previous versions also required more plumbing than I liked to, why it is constantly evolving towards less and less boilerplate code and more and more focus on the actual task at hand:
    Making reliable, easy understood and easily maintained code for end users.

    The trend with kbmMW continues... where there is need for plumbing code, there is a need for simplification, which will be reflect also in newer versions. Obviously that will not be on the cost of flexibility, since there may be very specific situations where one want to go as close to the metal as possible.

    Just my 3 braincell sparks.

  11. #11
    Eigenlijk wil je ook geen dataset op je smartphone.
    Waarom niet?

  12. #12
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Te veel overhead. Een smartphone is meestal een restclient naar een restserver. De enige data, die de smartphone nodig heeft, is platte data. Verder wordt alles verwerkt in de server.
    Nu weet ik niet hoe KBMMW dat doet op een smartphone, maar in principe komt de data vanuit de object. En e.v.t. teruggestuurde gegevens gaan ook via een object.

    Dit is wat ik weet en gelezen heb over deze materie. Ik ben geen expert. Wat ik wel weet, is dat het gebruik van BO de executable veel compacter en sneller maakt.
    Delphi is great. Lazarus is more powerfull

  13. #13
    Nu weet ik niet hoe KBMMW dat doet op een smartphone
    Zowel direct met objecten werken als met (memory)datasets is mogelijk.

    Ik had, nadat ik hoorde dat kbmmw ook smartservices heeft en een ORM, direct de neiging om alle datasets overboord te gooien. Nu neig ik ernaar om wel datasets te gebruiken maar dan alleen in mijn forms of in units die mijn form logica regelen. Zo combineer ik het beste van twee werelden (Tenminste dat hoop ik )

  14. #14
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Als je ORM backend de datasets op de client klein houdt (zeg honderden, lage duizenden), maakt dat niet zo veel uit.

  15. #15
    Dat is goed om te weten

Page 1 of 2 1 2 LastLast

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

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