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

Thread: Wat is OPF

  1. #1
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747

    Wat is OPF

    Marcov spreekt over OPF in deze topic.
    Maar wat is OPF?
    Delphi is great. Lazarus is more powerfull

  2. #2
    Silly member NGLN's Avatar
    Join Date
    Aug 2004
    Location
    Werkendam
    Posts
    5,133
    Goede vraag.

    OPF = Object Persisten(t)(ce) Framework.

    Oftewel: een ontwikkelingsraamwerk (framework) waarbij gegevens uit databases (DataSets in Delphi) worden "omgezet" in objecten. Dus dan heb je geen Query meer die je opent en waar je doorheen wandelt met First en Next, maar dan heb je objecten zoals bijvoorbeeld TKlanten. De eigenschap Items[i] levert dan een TKlant met routines zoals KopieerAlsLeverancier, Verwijder en Blokkeer, en eigenschappen zoals KlantCode, Naam, Adres, Contactpersonen, Offertes, Orders, etc... waarbij het adres weer een TAdres-object is met elk weer zijn eigen routines en eigenschappen, contactpersonen een TContactPersonen, offertes een TOffertes, etc...

    Afhankelijk van de implementatie, is het volgende theoretisch mogelijk bij een telefoontje van een klant die een bestelling wil doen a.d.h.v. de laatste offerte:
    Code:
      Customers.Current.Offers.Last.ConvertToOrder(Now);
    Voor Delphi zijn er meerdere implementaties waaronder TiOPF en JSON.
    Last edited by NGLN; 22-Oct-14 at 21:11.
    (Sender as TNLDUser).Signature := 'Groeten van Albert';

  3. #3
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Jup. Kort gezegd gebruikt een opf een orm naar een rdbms.

  4. #4
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Maar niet zo'n goede vraag (al kan het voor andere zijn) voor mij. Ik had het moeten associëren met tiOPF, waarmee ik al een tijdje (met onderbrekingen) aan het stoeien ben. Alleen wordt daar veel gesproken over Business Object Modules (BOM), waardoor ik de link niet goed heb gelegd. Een goede uitleg kan hier worden gevonden.

    Overigens doet Graeme Geldenhuys veel voor dit project. De demo werkt als een speer. Alleen de implementatie is lastig. Zal eens een goed artikel over geschreven moeten worden.
    Delphi is great. Lazarus is more powerfull

  5. #5
    Ik heb in Delphi geen ervaring met een OPF, voornamelijk omdat ik ze veel te omslachtig vond werken. In .NET is het andersom, daar werk ik eigenlijk alleen maar met een OPF. Maar dan ook alleen maar omdat de OPF de database voor me aanmaakt en onderhoudt en zelf de queries voor me maakt. Daarnaast kan ik ook direct databinden met de objecten van het OPF.

    Dus om het voorbeeld van NGLN aan te houden:

    Code:
    Customers.Current.Offers.Last.ConvertToOrder(Now);
    Dat zou de database kunnen aanmaken, of ervoor zorgen dat de laatste updates naar de database worden gepusht, en vervolgens wordt er een query uitgevoerd van de current customer in een join met zijn laatste offer en wordt daarna de method ConvertToOrder() van het Offer object aangeroepen. Het resultaat kan ik laten zien met <Label Text='<%# Item.OrderNr %>'.

    Kortom, de database wordt bijzaak en ik kan me focussen op het echte werk. Op die manier vind ik een OPF een verademing!
    Marcel

  6. #6
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Bij tiOPF is dat echt een nadeel. Je moet zelf zorgen voor dat queries. Echter is er wel een tool (MGM), die de BOM voor je maakt, waardoor je flexibeler aan de slag kan. Maar voor een beginner blijft het omslachtig.

    Bij Delphi.be wordt mORMot besproken. Ben benieuwd.
    Delphi is great. Lazarus is more powerfull

  7. #7
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Op papier zouden recente versies van Delphi alles zo'n beetje moeten hebben. Extended RTTI en custom attributes en databindable grids (via die livebindings tjoep van FM). Het probleem is dat de meeste frameworks dit niet gebruiken. Zoals zo vaak tegenwoordig hebben veel projecten moeite D7-D2007 los te laten, deels terecht, want de stabiliteit en afwerking van veel recente features is maar zozo. En er moet natuurlijk een hele tooling en DB layer rond geschreven worden. Embarcadero pikt het niet echt op, en de rest is gefragmenteerd.

    Een van de problemen met OPF die ik heb is dat het simpelweg ingewikkelder is. Tenzij je oplossingen van een bepaald type aan de lopende band maakt, loont het niet.

    Beide mijn vorige banen gebruikte een OPF, beide webapps in Delphi. De eerste echter zonder RDBMS (maar naar DBF/flat file, relationeel, maar simpel van opzet), geheel custom. De tweede was een webapp, hybride OPF en relationeel (clientdatasets vanwege databinding). Het was origineel op een TDBroot skelet (geen flauw idee waar dat vandaan kwam) gebaseerd systeem, dat later half geupgrade was naar een latere versie met eigen lagen en tooling erover heen.

    De objecten en hun bindings werden vanuit de table definities (SQL server 2005) gegenereerd (delphi code dus, inclusief container types die typesafe waren, dit was pre generics), maar voor meer ingewikkelde (JOIN-) entiteiten kon die daarbij externe data raadplegen. (XML met correcties en extra typing) Het voordeel was dat zelfs bij ingewikkelde objecten een veld toevoegen wel met een simpele regeneratie doorpropageerde, terwijl het "ingewikkelde" gedeelte handgecodeerd bleef. Er kon op die manier ook typing worden toegevoegd. (dus b.v. een "string" type in de db een speciale betekenis geven in Delphi, en daar speciale getters en setters voor genereren)

    Maar goed, dat was een applicatie waar in de hoogtijdagen 10-15 man op zaten, en doorgaans zo'n 3-4 fulltime.
    Last edited by marcov; 23-Oct-14 at 14:38.

  8. #8
    Maar ook dan bleef er nog veel handwerk over denk ik marcov?

    Altijd wel grappig om te bepalen wat nou leidend is. Gebruik je code first waar de database aangemaakt en onderhouden wordt, of gebruik je design first waar je vanuit de database een model genereert? Ik ben zelf groot voorstander van die eerste, maar een database purist is daar misschien wat angstig voor.
    Marcel

  9. #9
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Marcel View Post
    Maar ook dan bleef er nog veel handwerk over denk ik marcov?
    Ik kwam er later als senior programmer bij toen de orginele developer weg ging rond het moment een major revisie live had moeten gaan, en hoewel ik dus niet weet hoe het originele framework tot stand kwam, weet ik dat het evolutionaire manier van ontwikkeling is geweest over jaren en projecten.

    De manier van uit de database geneneren is overigens wel van mij. Hoewel dat origineel dat ook eenmalig gedaan was (toen de app nog geen zesde van de tabellen was), maar daar was daarna zwaar met de hand ingegrepen. Toen ik begon compileerde het import tool niet eens. (o.a. sql server versie verandering)

    Maar eigenlijk viel framework onderhoud viel wel mee eigenlijk (over 1.5 jaar). Het probleem was meer dat de origineele implementatie erg naief was. (veel temp tabellen, queries recht toe rechtaan, enz) Ik heb meer performance tunen gedaan dan overig framework werk bij elkaar. Met name omdat steeds meer detail informatie ipv constanten in de delphi code in de db werden gestopt (en de joins dus steeds groter) was met name het uitzoeken van "nolock" de grote doorbraak, alsmede het cachen van tabellen die maar eens per kwartaal veranderden en een aantal ingewikkelde paginas. (er zijn daar vast nog topics over op nldelphi)

    Er was wel erg veel businesscode (1200+ tabellen in de app) om die framework kosten op af te schrijven.

    Altijd wel grappig om te bepalen wat nou leidend is. Gebruik je code first waar de database aangemaakt en onderhouden wordt, of gebruik je design first waar je vanuit de database een model genereert? Ik ben zelf groot voorstander van die eerste, maar een database purist is daar misschien wat angstig voor.
    Ik heb geen voorkeur. Het hangt een beetje van het probleem, en de bestaande code af, helemaal met een schone lei begin je immers maar zelden. Dat zie je b.v. in mijn eerste baan. (rond de tijd dat ik op nldelphi kwam). OLAP achtig en dataset paste in geheugen, en was grotendeels readonly. Die randvoorwaarden waren ZO belangrijk. De basis keuze (alles in geheugen, mutaties naar disk) was controversieel, maar na de eerste inspanning was je van elk performance probleem af, als je je query zo formuleerde dat de eerste conditie met een geindexeerde waarde samenviel (eigen framework, dus dat ging niet automatisch). Die keuze was overigens Stephan's verdienste, niet de mijne.

    Consequent zijn en over elke deelstap nadenken, en analyse van het probleem heb ik hoger in het vaandel staan dan design principes tot de laatste letter volgen. Blijven denken dus, en niet slaafs mantras volgen. Met meer man zijn is daarbij overigens een voordeel, kan je gaten in elkaars redenering schieten.

    En altijd een torture tooltje maken/zoeken. Een vroege waarschuwing wanneer performance problemen aanstaande zijn is enorm belangrijk.
    Last edited by marcov; 23-Oct-14 at 17:12.

  10. #10
    Stijn Sanders develyoy's Avatar
    Join Date
    Jun 2008
    Location
    GentBrugge, Belgi?½
    Posts
    1,046
    Ik las net nog deze daar daar ook een beetje over gaat.: http://www.theregister.co.uk/2014/10...odelling_tool/

    Ik ben zelf niet zo voor OPF/ORM. Ik begrijp dat er andere mensen heel erg voor gewonnen zijn, en waarschijnlijk zijn er wel projecten waar je zo veel werk uitspaart, maar uit mijn eigen praktijkervaring kan ik zeggen dat ik altijd al heb gezien dat het werk dat je met zoiets uitspaart later terug ziet komen. Als er heel veel verschillende 'dingen' moeten worden bewaard in je database, en daar zijn heel weinig uitzonderingen op, dan kan dat lukken, maar in de praktijk zitten er altijd van die lelijke uitzonderingen die om aan een elegante oplossing te komen eigenlijk dwars door je abstractie-laag moeten.

    (Los van dat er een bepaald security risico is, ik dacht dat dat onder andere bij deze aan bod kwam: http://google-gruyere.appspot.com/ )

  11. #11
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Bij OPF gaat het niet perse altijd om een volledige top-down benadering waarbij je alles uit een model genereert. Dat is natuurlijk leuk voor de presentaties, maar in feite gaat het vooral om de abstractie die de business code ziet. Denk daarbij aan later verfijnen of veranderen (b.v. caching, naar andere machine gooien enz), en deze laag zonder (veel) beperkingen zo te stileren dat het fout vermijdend werkt.

    Ik zie eerdere minder security risks bij OPF, typisch is de database laag in hoge mate gecentreerd en geabstraheerd, wat SQL injectie e.d. lastiger maakt.

    Je kan je overigens afvragen of OPF wel echt objectgeorienteerd is, met name of het polymorfische aspect wel voldoende aan bod komt, vooral in de business code die eigenlijk centraal zou moeten staan. Het is meer dat het niet relationeel is denk ik.

  12. #12
    Marius
    Join Date
    Jul 2013
    Location
    Groningen
    Posts
    178
    We gebruiken al jaren een doorontwikkelde versie van tiOPF (destijds versie 0.7). Die Greame is ondertussen heel indrukwekkend aan het door ontwikkelen geweest! Wij gebruiken zelf een mix van objecten en queries want je krijgt van zijn levensdagen niet alles in een OPF/ORM gepropt (daar zou je de rest van je leven mee bezig zijn). Er is tegenwoordig een hele nieuwe modern OPF/ORM van TMS Auerilius genaamd http://www.tmssoftware.com/site/aurelius.asp (niet gratis). Deze werkt compleet met de nieuwe RTTI en generics. Ik heb echter geen idee hoe ze die objecten aan controls koppelen.

    Overigens beheren we de database helemaal zelf want dat vertrouw ik geen enkel OPF toe (zelfs niet .net).

    Groetjes, Marius

  13. #13
    Silly member NGLN's Avatar
    Join Date
    Aug 2004
    Location
    Werkendam
    Posts
    5,133
    Quote Originally Posted by Marius2 View Post
    Ik heb echter geen idee hoe ze die objecten aan controls koppelen.
    Dat is inderdaad ook een groot verschil met de standaard reeds ingebouwde DataSet benadering.
    (Sender as TNLDUser).Signature := 'Groeten van Albert';

  14. #14
    Marius
    Join Date
    Jul 2013
    Location
    Groningen
    Posts
    178
    Quote Originally Posted by NGLN View Post
    Dat is inderdaad ook een groot verschil met de standaard reeds ingebouwde DataSet benadering.
    Kleine correctie dan

    Wij gebruiken mediators net zoals tiOpf (datasets are evil en ik ben blij dat we daar vanaf zijn!)
    Wat Auerilius gebruikt weet ik echter niet (en daar ben ik juist heel nieuwsgierig naar)

    gr, me

  15. #15
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Datasets are evil. Dat heb ik nou ook altijd gevonden
    Vertel eens Marius: wat is er zo evil aan? Overtuig ons

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
  •