Page 2 of 2 FirstFirst 1 2
Results 16 to 27 of 27

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

  1. #16
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,904
    Runtime typing en serializatie/deserializatie van zeg json objecten is denk ik eerder langzamer dan sneller dan datasets, en daar ligt tegenwoordig ook niemand wakker van

  2. #17
    Ik zou me er sowieso niet al te druk over maken. Een TClientDataset is ook weer niet zo inefficient om data in op te slaan, alleen string velden met een hoge size zijn inefficient. En dan nog, elke telefoon heeft 2GB of meer geheugen, vaak meer dan 4. Ik weet niet of je voor de desktop al over bent op 64 bit Delphi, maar zo niet, dan heb je nog nooit een programma geschreven dat meer dan, zeg, 1.5 GB geheugen gebruikte, en dat is dus inclusief grote dikke fat client applicaties die je misschien in beheer hebt gehad. Natuurlijk zijn telefoons minder krachtig dan PC's, maar datasets afzweren is onnodig, en je moet de vervanger nog maar eens beter zien te krijgen. Prima overigens om het anders op te lossen, maar niet met geheugen als reden.
    1+1=b

  3. #18
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,492
    Ik zou me er sowieso niet al te druk over maken
    Er zal toch een reden moeten zijn dat de ene helft zweert over het gebruik van BO en de andere gebruik maakt van de traditionele TDataset. rik.osstyn en SamWitse zweren daarbij.
    Delphi is great. Lazarus is more powerfull

  4. #19
    het ene hoeft het andere toch niet uit te sluiten?

    Ik gebruik regelmatig datasets om dingen makkelijk weer te kunnen geven in mijn gui. Data komt dan uit xml of json berichten, vaak zit daar dan nog een hoop logica tussen. In Delphi en zeker met vcl is de dataset een ideale component om de boel aan elkaar te knopen.

  5. #20
    Ik zeg niet dat je geen BO moet gebruiken, maar de reden daarvoor is dat je een beter onderhoudbare/begrijpbare applicatie schrijft, niet omdat het meer of minder geheugen gebruikt. Laatst toevallig nog zo'n soort opzetje gemaakt. Een BO met logica, met aan de ene kant een repository die eigenlijk gewoon een datamodule met ADO datasets was, en aan de andere kant een viewcontroller die client datasets aanbood om er makkelijk een schermpje aan te kunnen hangen. Bijna de klassieke opzet dus, behalve dan dat ik alles tot aan de queries wel netjes kon unit testen. Volgens mij zit het voordeel daarin, en niet in milliseconden of megabytes.
    1+1=b

  6. #21
    Misschien moet ik mijn vraag anders stellen...

    Stel dat je geen dataset gebruikt hoe zou je dan undo functionaliteit en toch een soort van datastate kunnen bijhouden op een makkelijk manier? Het lijkt mij vrij omslachtig om dit zelf te schrijven en volgens mij eindig je dan met een zelfgeschreven dataset achtige.

  7. #22
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,904
    Als de records immutable zijn, dan gewoon een lijst met mutaties. En dat werkt ook over meerdere entiteiten heen, niet alleen binnen een en dezelfde dataset.

  8. #23
    Maar wat als ze niet immutable zijn? De enige simpele, maar in mijn ogen lelijke oplossing, is modal forms gebruiken voor edits/inserts

  9. #24
    Dat zie ik niet helemaal. Hoe voorkomt een modal form die problemen? Over wat voor undo heb je het dan, en tot welk moment wil je die kunnen doen? Nog nadat de data is opgeslagen in de database?
    1+1=b

  10. #25
    Misschien ben ik wat onduidelijk geweest. Als je data-aware controls gebruikt dan veranderd het gedrag afhankelijk van de state van de dataset. Bij een edit mode kun je data aanpassen, maar in een browse mode niet. Als je modal forms gebruikt met niet data-aware controls dan hoef je niet echt een state bij te houden, want het modal form is er alleen als er ge-edit/ge-instert wordt. Hoop dat het iets duidelijker is.

    Wat betreft undo functies. Ik bedoel voordat de data is opgeslagen in de database. Bij een dataset krijg je bij een edit cancel weer de oorspronkelijke waarde van voor de edit. Zonder dataset zul je zelf iets moeten regelen, of bijvoorbeeld pas de data uit de controls halen vlak voordat het naar de database gaat.

  11. #26
    Quote Originally Posted by luigi View Post
    Misschien ben ik wat onduidelijk geweest. Als je data-aware controls gebruikt dan veranderd het gedrag afhankelijk van de state van de dataset. Bij een edit mode kun je data aanpassen, maar in een browse mode niet. Als je modal forms gebruikt met niet data-aware controls dan hoef je niet echt een state bij te houden, want het modal form is er alleen als er ge-edit/ge-instert wordt. Hoop dat het iets duidelijker is.

    Wat betreft undo functies. Ik bedoel voordat de data is opgeslagen in de database. Bij een dataset krijg je bij een edit cancel weer de oorspronkelijke waarde van voor de edit. Zonder dataset zul je zelf iets moeten regelen, of bijvoorbeeld pas de data uit de controls halen vlak voordat het naar de database gaat.
    You are touching something important... regular objects do not as such keep a state, unless you device a custom state management for them, while TDatasets do provide a state.
    Typically REST wise, the scenario is to have one REST function to call for creating or changing data (providing a serialized object or array with data) and one for deleting data (providing IDs of the ones to delete). Then you, as a developer will have to shoehorn your client into calling the right REST function depending on the user interaction.

    With n-tier setups I think that easier ways should exist, that both provides the typical REST interface as described above (to be compatible with any REST capable client), and the ability to take advantage of the state management in TDataset, which plays so well with datacontrols in VCL apps.

    For that reason kbmMW comes with a kbmMWSmartClient unit, which includes various functions, of which one of them can be called:

    remoteclient.ORM.Persist<TYourObject>(YourDataset, 'delete','update');

    What it does is take yourDataset, split it up in lists of objects of type TYourObject, depending on if the objects are new/modified or deleted.
    Then it will automatically call the server potentially twice... one for updating/creating data and one for deleting data. The names of the methods for creating/modifying and deleting, are given.

    Newly created objects, will have a primary ID that is NULL, while the ones that will need update does have a non NULL primary ID. The ones to be deleted also all have a non NULL primary ID.

    For this to operate, one should declare TYourObject properties as nullable:

    TYourObject = class
    private
    FID:kbmMWNullable<string>;
    FName:kbmMWNullable<string>;
    ...
    public
    property ID:kbmMWNullable<string> read FID write FID;
    ...
    end;

    In fact nullable properties is able to track if the data has been modified since originally receiving it and kbmMW also takes advantage of that to ensure non created, non modified objects are not attempted to be handled.

    best regards
    Kim/C4D

  12. #27
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,492
    Quote Originally Posted by luigi View Post
    Zonder dataset zul je zelf iets moeten regelen
    Dat klopt. Als je een object TPersoon aanmaakt, weet deze totaal niet welke oorspronkelijke waarden aanwezig zijn na een wijziging. Ik weet dat TIOPF in zijn framework 'onder water' een extra object aanmaakt met de oorspronkelijke waarden. Als de undo/cancel wordt gebruikt, wordt dat object aangeroepen en de oorspronkelijke waarden weer teruggegeven. Naar mijn weten slaat mORMot deze 'oude' waarden op in zijn interne SQLite database.

    We zijn eigenlijk verpest door dele vele handigheden van bestaande frameworks. Zij doen allemaal jouw werk voor communicatie. Wil je echt weten hoe het zit, zal je diep in de code moeten kijken. En vaak zijn dat zulke constructies, waarvan boven je (mijn) pet gaat.

    Maar ik vind je project wel leuk.
    Delphi is great. Lazarus is more powerfull

Page 2 of 2 FirstFirst 1 2

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
  •