Marcov spreekt over OPF in deze topic.
Maar wat is OPF?
Marcov spreekt over OPF in deze topic.
Maar wat is OPF?
Delphi is great. Lazarus is more powerfull
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:
Voor Delphi zijn er meerdere implementaties waaronder TiOPF en JSON.Code:Customers.Current.Offers.Last.ConvertToOrder(Now);
Last edited by NGLN; 22-Oct-14 at 21:11.
(Sender as TNLDUser).Signature := 'Groeten van Albert';
Jup. Kort gezegd gebruikt een opf een orm naar een rdbms.
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
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:
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 %>'.Code:Customers.Current.Offers.Last.ConvertToOrder(Now);
Kortom, de database wordt bijzaak en ik kan me focussen op het echte werk. Op die manier vind ik een OPF een verademing!
Marcel
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
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.
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
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.
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.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.
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.
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/ )
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.
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
Datasets are evil. Dat heb ik nou ook altijd gevonden
Vertel eens Marius: wat is er zo evil aan? Overtuig ons
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks