Page 5 of 10 FirstFirst ... 3 4 5 6 7 ... LastLast
Results 61 to 75 of 144

Thread: Business Objects - het begin.

  1. #61
    Of je gedeeltes van je BO ook op de client beschikbaar hebt (zonder ze in de GUI te mengen).
    Zo doe ik het in feite nu. De testen staan op een datamodule (meestal) en worden aangeroepen door bv een onchange of onexit van de GUI, of door een van de dataset/datasource events.

    Roundtrips naar mijn server probeer ik zoveel mogelijk te voorkomen, maar dat zou inderdaad ook kunnen.

  2. #62
    senior member PeterVercruysse's Avatar
    Join Date
    Nov 2006
    Location
    Rijsel
    Posts
    1,608
    Maar als je heel veel klanten hebt voor je product en je ze allemaal zo veel als mogelijk van dienst wil zijn ontkom je er niet altijd aan.
    Handig hierbij zijn de variant-fields ( DataType ftVariant ), maar deze zijn wel iets trager.

    Nu het voorbeeldje BDE/ADO. Hierbij kan men een volledig project overschakelen van ADO naar BDE ( of wat dan ook ) door het vervangen van één regel code. Het voorbeeld is wat simplitisch, maar daarom is het een voorbeeld.

    DbDemos werkt niet met DbExpress, maar dit is ook perfect mogelijk om dit te implementeren
    Attached Files Attached Files
    Last edited by PeterVercruysse; 08-Dec-07 at 01:45.
    Gras groeit niet sneller door er aan te trekken

  3. #63
    Ik denk dat Business Objects en MemoryDataset in feite dezelfde laag is.
    In het model dat ik gebruik is een Business Objects Object afgeleid van een Memory-dataset, maar dat hoeft natuurlijk zo niet te zijn. De definitie van een Object is in principe een hoeveelheid data die afgeschermd wordt van de buitenwereld door eigen code die deze data afschermt en dat principe wordt hier letterlijk toegepast op een database-model. Een van de grote verschillen met de klassieke modellen is, dat hier veel meer gebruik gemaakt wordt van afleiding en het overschrijven van virtuele methodes, dan gebruik te maken van instatiëring en events. Hierdoor wordt veel meer zaken afgehandeld door het ( meestal aan een tabel gelinkte ) object en wordt de business, die er boven ligt, voor een groot stuk ontlast. In de praktijk zorgt dit (meestal) voor beter gestructureerde code en een verbeterde onderhoudbaarheid van het systeem.

    Dit kan een database zijn in de breedste zin des woords.
    In de praktijk komt men ook Ini-file en Registry-Objecten tegen. Dit zijn objecten die afgeleid worden van bijvoorbeeld Tregistry. Uiterlijk zien deze er net zo uit als een BO-Object, maar deze hebben natuurlijk geen Dataset-mogelijkheden.

    Ik kan me voorstellen dat er nog een extra objectlaag is die alleen een TTable of TQuery gebruikt voor de opslag, maar verder gaat door de database structuur af te schermen voor de BO's. Deze laag kan ook zorgdragen voor het aanpassen van de database structuur, indien dat nodig is.
    In de praktijk is deze laag meestal niet zo indrukwekkend groot niet. In de praktijk bestaat dit uit een relatief kleine object-set. Meestal heb je hier de keuze uit verschillende sets die compatibel zijn met elkaar. Bijvoorbeeld een BDE-set, een ADO-set een IBX-set. Je kunt gewoon veranderen van technologie door een andere set te maken en het in te pluggen in het bestaande framework.

    Eventueel kan een BO dit ook gedeeltelijk afdwingen door triggers of constraints te maken in het datamodel.
    Zowel het BO-datamodel as de database kan gebruik maken van triggers, stored procedures, referentiele integriteit en contraints. Zaken zoals triggers werken onafhankelijk, maar in principe worden database-stored procedures altijd opgeroepen vanuit een BO-object, waar ze opgeroepen worden via een method.
    De verbazing begint waar de kennis ophoudt

  4. #64
    Ik zou denken dat die tussenlaag wel iets groter is dan dat. Een complexe query die uit meerdere tabellen data sprokkelt voor één BO zal wellicht niet op elke database werken. Door een aparte opslaglaag te maken, kun je je query optimaliseren voor een specifieke database, of kun je eventueel een eigen bestandsformaat definiëren voor de opslag.
    Door je opslaglaag 'slim' te maken, zodat deze bekend is met je BO's, kun je dus een volledige scheiding aanbrengen tussen BO en database, en toch meer flexibiliteit en optimalisatie toepassen, dan wanneer je je BO rechtstreekt met een willekeurige TDataSet afgeleide laat praten.
    Je opslaglaag wordt dan wel groter en complexer, maar daar haal je wel degelijk winst uit.

    In eerste instantie kun je de gegevens overigens wel direct doorpompen naar een TDataset, maar die functionaliteit zou ik dan toch in een aparte opslaglaag stoppen. Deze laag is dan algemeen voor het werken met alle datasets, maar door de scheiding kun je dan later uitbreiden met database-specifieke optimalisaties, zonder dat je daarmee daadwerkelijk je BO's vervuilt.
    1+1=b

  5. #65
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Goleztrol: dat is precies de afweging die wij ook moesten maken. Maar je moet dan wel voor iedere @!#**@$ query een OOP laag gaan ontwerpen, en dan ook nog eens met wat database onafhankelijkheid.

    Voor allebei valt wat te zeggen (abstractie en eenvoud: pass through), wat wij gedaan hebben is db afhankelijkheid alleen in de globale structuur een plaats geven, en voor read-only overzichten een hand lichten aan de OO structuur.

    Dit laatste omdat het gewoonweg erg makkelijk was de resultaten van een query direct de presentatie laag (lees: de serverside webpagina templates) in te gooien, na een kleine automatische transformatie. De data viel zeg maar compleet door de BO/CO lagen heen.

    De formele scheiding hielden we veel strakker aan voor de daadwerkelijke business code. Daar was onderhoud en leesbaarheid ook veel belangrijker.

  6. #66
    Een van de nadelen van de discussie over abstracte data is dat de uitleg ook abstract begint te worden. Keren we terug naar een van de oorspronkelijke diagrammen:

    MemoryDataSet -- TransportLayer -- Database.

    De transportlayer kan in in principe twee delen opgesplitst worden:
    1. De objecten die zorgen voor de transport van data van en naar de MemDataset. Deze zijn database/opslagsysteem afhankelijk.
    2. De code die zorgt voor transformatie van data tussen het transport en de MemDataset.

    1. De transport-objecten zijn meestal afgeleid van de typische BDE-, ADO-, DBE-componenten, maar het kunnen natuurlijk van de meest exotische dingen zijn ( zoals een TRegistrydataSet of XML, ... ). Deze objecten zorgen er dan ook niet alleen voor dat al de eigenaardigheden van elke systeem zo veel mogelijk worden weggewerkt, maar gaan ook een aantal systeem-afhankelijke optimalisaties gaan uitvoeren. Deze objecten hebben natuurlijk ook hun beperking, maar leveren meestal zeer goede prestaties.

    Hoe dan ook, het belang van deze dingen is, dat ze onderling uitwisselbaar zijn, zodat je ze, in principe, moeiteloos kunt verwisselen.

    2. Bij het ‘overschrijven’ van de code van het transport-object naar de memdataset gebeuren ook een aantal manipulaties zoals het toevoegen van calculated fields, veranderen van veldnamen, … . Deze code is in principe database-onafhankelijk.

    Maar, zoals Marcov al vertelde, in de praktijk zijn er een aantal zaken die meestal door de mazen van het net glippen. Voor tabellen zoals Muntcodes, Landcodes, Aanspreektitels, … en weet ik wat nog allemaal die we hier hier gerust statische masterdata zouden kunnen noemen, gaat men meestal geen BO-objecten gaan gebruiken, maar meestal een geparameteriseerd invoerprogramma.
    De verbazing begint waar de kennis ophoudt

  7. #67
    Hmm volgens mij komen we nu op een fundamentele discussie. Theorie heb ik meestal een broertje dood aan, het moet praktisch gewoon werken.

    In mijn optiek is een BO GEEN dataset, het communiceert er hoogstens mee. Als dat wel zo zou zijn, had je geen BO nodig maar zou je gewoon de TDataset gebruiken. Dat staat los van waar die dataset zijn data heeft staan.

    Deze discussie is ook wel lekker vaag aan het worden intussen. Volgens mij zijn er gewoon 2 kampen te onderscheiden.

    1. De echte OPF jongens zoals LordLarry (bijvoorbeeld). Die gebruiken volgens mij een wrapper om data te lezen en schrijven naar een database en de info onder te brengen in objecten. Je hebt dus in feite intelligente data (weet even geen betere omschrijving) die duidelijk gedefinieerde methodes heeft om zijn eigen inhoud aan te passen.

    2. De dataset jongens zoals ik. Ik praat zelf niet over BO of business objecten of een van de andere buzz words. Bij mij heet het logica en die zit zoveel mogelijk op mijn server in services en als dat niet kan op datamodules. Van die datamodules kun je dan natuurlijk in een aantal gevallen weer afgeleides gebruiken.

    Het meest belangrijke van deze hele discussie is volgens mij dat je je bewerkingen op je gegevens logisch in elkaar steekt en zoveel mogelijk op een plaats onderbrengt.

    Je presentatielaag is dus in feite niet meer dan een klein schilletje, die hoogstens wat acties in achterliggende lagen kan triggeren. Een win32 app ombouwen naar een web app zou dan niet meer dan een vloek en een scheet moeten zijn.

    Tja in een ideale wereld ................

  8. #68
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Maar, zoals Marcov al vertelde, in de praktijk zijn er een aantal zaken die meestal door de mazen van het net glippen. Voor tabellen zoals Muntcodes, Landcodes, Aanspreektitels, … en weet ik wat nog allemaal die we hier hier gerust statische masterdata zouden kunnen noemen, gaat men meestal geen BO-objecten gaan gebruiken, maar meestal een geparameteriseerd invoerprogramma.
    Rik:
    Laag mutatie tabellen waren volledig gecached. Kleine moeite, groot performance verschil (gemiddelde query heeft minder joins).
    Nu juist de lage mutatie tabellen zijn hier ideaal voor, omdat je nog steeds stateless en gedistributeerd kan werken. (al is dat niet mijn ding, maar goed, hier was daar al voor gekozen)

    Enne, Businessobjects zijn niet hetzelfde als memdatasets :-)

    Benno: het punt is de logica onafhankelijk te maken van storage laag, en relatief op een hoog niveau. Ik heb zelf geen datasets gebruikt, maar het zou interessant zijn jouw visie daarop te horen hoe dat werkt in de praktijk. Het klinkt mij eigenlijk in de oren als een soort Java voor databases. Je creert je eigen database abstractie (Java het platform, of de TMemDataset), en probeert het dan achter op de reeele database te mappen

  9. #69
    maar het zou interessant zijn jouw visie daarop te horen hoe dat werkt in de praktijk
    Die heb ik een paar posts terug al gegeven volgens mij.

    IK heb services die in feite hapklare data aanleveren (meestal in een dataset). Ik gebruik dus bijna overal dataaware controls.

    Als er in mijn GUI aanpassingen zijn gedaan op die dataset gebruik ik een resolve (ik stuur een delta terug naar de server) en die regelt het verder.

    Soms is dat alleen opslaan in de database. Maar bv een order mutatie zou ook in kunnen houden het bijwerken van een voorraad. Dus een service roept dan een andere service aan met een aantal parameters, om die voorraad aan te passen.

  10. #70
    In mijn optiek is een BO GEEN dataset
    Uiteraard niet. Ik zie niet waar ik dat geschreven zou hebben, maar enfin, het bezonderste is dat we daarover eens zijn. Een BO omvat zoals elk object data en code. Zijn data kan bijvoorbeeld een memdataset zijn.

    Laag mutatie tabellen waren volledig gecached. Kleine moeite, groot performance verschil (gemiddelde query heeft minder joins).
    Nu juist de lage mutatie tabellen zijn hier ideaal voor, omdat je nog steeds stateless en gedistributeerd kan werken.
    Uiteraard is dit zo. In principe kun je hier nog een tweetal technieken gaan aan toevoegen:

    1. De Incremental Select:Toepasbaar met grote datasets. Na elke select wordt een timestamp bijgehouden. Bij een nieuwe select wordt enkel de nieuwe data opgehaald en wordt je mem-dataset ermee aangepast. Dit heeft de volgende voordelen:

    a. De client heeft nauwelijks hinder van het refreshen van de data.
    b. Na het initieel ophalen van de data, heb je nauwelijks nog netwerk/serverbelasting
    c. Ook het verhogen van de refresh-rate heeft geen merkbare verhoging van de netwerk/server belasting.

    2. De Sync Dataset: Toepasbaar in een 3-tier omgeving. Op een applicatieserver staat een mem-dataset met daaraan gekoppeld mem-dataset-clients op elke client. Bij een update op een client, wordt de update na verificatie door de applicatieserver doorgestuurd naar elke van de clients. De implementatie is wat moeilijker, maar deze dingen werken gewoon sneller dan je schaduw.
    Last edited by rik.osstyn; 10-Dec-07 at 21:07.
    De verbazing begint waar de kennis ophoudt

  11. #71
    2. De Sync Dataset: Toepasbaar in een 3-tier omgeving.
    Yep. IBM heeft daar goede resultaten mee gehaald, zoek maar eens op messaging.

    Het hoeft niet perse een dataset te zijn natuurlijk, maar het mechanisme is inderdaad zeer krachtig.

    In kbmMW zit het ook, daar heet het messagingtransport. Vaak compineer je dat in een WIB. Het hele systeem is in feite een asynchroon publish subscribe systeem, waardoor je ook flexibel data kunt pushen naar clients.

    Volgens mij is RSS de in het wild gesignaleerde variant van dit principe.
    Last edited by Benno; 10-Dec-07 at 21:51.

  12. #72
    Ik ken dit voornamelijk in combinatie met BO, gezien het real-time karakter komt het goed tot zijn recht in de SCADA/HMI wereld en de financiële wereld ( beursnotaties, billboards, ... ) waar verschillende schermen dezelfde informatie tonen.

    Voor administatieve systemen is het nauwelijks bruikbaar.
    De verbazing begint waar de kennis ophoudt

  13. #73
    Voor administatieve systemen is het nauwelijks bruikbaar.
    Een paar voorbeelden dan:

    • Een verkoop systeem voor gebruikte auto's. De client krijgt automatisch updates over aanbod en verkoop.

    • Een boekingssysteem voor vergaderruimtes.

    • Verkoopsystemen, waar je realtime de voorraadstatus kunt controleren

    • Benno's updatesysteem voor lookuptabellen


    Zat toepassingen ook administratief dus. Maar je hebt wel gelijk dat het nog niet echt ingeburgerd is en das jammer.

  14. #74
    senior member PeterVercruysse's Avatar
    Join Date
    Nov 2006
    Location
    Rijsel
    Posts
    1,608
    Tot nogtoe werd/wordt er de relaties tussen BO en Database besproken, terwijl er toch een grote nood is om ook een GUIDataSet (=een dataset waaraan je je data-componenten, zoals TEdit, TDBGrid, van je GUI koppelt) in je business objects te voorzien.
    Sam, zoals ik de zaken hier begrijp, vormt is de GUIDataset dan toch gewoon de Memdataset van je BO, of gaat deze redenering niet op ?
    Gras groeit niet sneller door er aan te trekken

  15. #75
    Met een intelligentieniveau iets boven de gemiddelde Delphi-programmeur en een tiental jaren programmeren in Delphi op mijn teller, ben ik ondertussen een senior geworden, of tenminste, dat dacht ik, tot ik deze thread hier begon te lezen. Gui-datasets, abstracte layers, Object persistente frameworks, in de database gestreamde memdatasets, incrementele selects, ...

    Ik bedoel: waar halen jullie al deze kennis vandaan? Worden jullie collectief wakker met het idee of is er een gemeenschappelijke bron? Deze had ik in elk geval nog niet gevonden en ik schuim, zoals iedereen hier waarschijnlijk, bijna dagelijks het internet af, maar ik vind zelden iets hierover, of tenminste niet iets wat bruikbaar is.

    Daarom was ik in het begin wat terughoudend, maar ondertussen moet ik toegeven, dat hoe meer ik lees, ik meer en meer overtuigd begin te worden van het principe dat er voor zorgt dat alles goed in elkaar past en dat ik er in principe, eerder onbewust, naar op zoek was.

    Als wat hier hier schrijf wat negatief klinkt, dan is dit zeker niet mijn bedoeling, ik vraag me gewoon af waarom dat ik niet op dit idee gekomen ben ( zoals Sam hier in het begin ).

    De hamvraag is alleen: hoe begin je aan zo iets?

    Starten met een commercieel produkt ( zoals OPF er één is dacht ik ), maar dan heb ik de vrees dat alles een beetje overhoop gegooid wordt, voor zover ik het zo een beetje begrijp.

    Of starten met de gegevens voorbeeldjes hier, vertrekkende van de handleiding ( die trouwens van goede kwaliteit is, maar volgens mij nog niet compleet ). Alles lijkt mij logisch, maar het lijkt mij minder evident om het zelf te doen.

    Of de concrete vraag: Welk systeem gebruik je het best en met welke methodes kun je het best gebruiken om alles over te zetten, wat zijn jullie ervaringen op dit gebied.

Page 5 of 10 FirstFirst ... 3 4 5 6 7 ... 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
  •