Page 4 of 10 FirstFirst ... 2 3 4 5 6 ... LastLast
Results 46 to 60 of 144

Thread: Business Objects - het begin.

  1. #46
    Dan kan men enkel specifieke velden toevoegen volgens de gebruiker. Dus niet in de design maar in run-time of heb ik het mis.
    Je hebt het mis

    Vrije door de gebruiker toe te kennen (of te benamen) velden zijn een mooi iets in een applicatie. Als je dat wilt zou ik daar in mijn datalaag rekening mee houden, bijvoorbeeld door een tabel die die info kan bevatten.

    Om op de opmerking van Arno terug te komen (de telefoonnummers) zijn oplossing is er een. Zelf zou ik als je meerdere adressen of telefoonnummers verwacht in de toekomst een koppeltabel gebruiken.

    In het algemeen wil je je metadata niet aanpassen. Bij een database loont het de moeite om in het begin van het project even aandacht te besteden aan je database ontwerp. Je zult zien dat je dan maar zelden een metedata aanpassing hoeft te doen. Uiteraard moet dan op voorhand wel je functionaliteit duidelijk zijn.

    Tools waar je on the fly je metadata aan kunt passen (zoals Access) zouden verboden moeten worden. Je wilt niet weten wat je in het wild aan access databases tegenkomt die zijn opgezet met de beste bedoelingen maar vanuit structuur doffe ellende zijn. Soms zijn bedrijven op een zeker moment afhankelijk van dat soort databases, levensgevaarlijk.

    [EDIT]Benno leer eens lezen (of schrijf alleen berichten als je wakker bent). Arno gebruikt in zijn voorbeeld al een koppeltabel [/EDIT]

  2. #47
    Christophe
    Join Date
    Jan 2004
    Location
    Belgium, West-Vlaanderen, Nieuwkerke
    Posts
    459
    Hoe werd dan de relatie tussen de Business Objects en de GUI?
    Is dit dan met een IInterface (IObserver)
    Of hoe kan een wijziging van een property van mijn class doorsturen aan een Form?

  3. #48
    Quote Originally Posted by ArnoBrinkman View Post
    Na mijn mening haal je metadata en data door elkaar.
    Met jou voorbeeld voor een tweede telefoonnummer heb ik eerder volgend model in gedachten:

    [1-n relatie tussen klant en telefoonnummer ]
    Dat werkt leuk als je van te voren weet waar je extensibility punten liggen. Als je dat niet weet en je nog flexibeler wilt zijn kan je je BO's en je DA's ook gewoon extra velden laten invoegen. Die hoeven zelfs niet eens in de originele tabel te staan, maar kunnen in een aparte extra velden tabel komen.
    Last edited by Lord Larry; 06-Dec-07 at 12:51.
    We adore chaos because we like to restore order - M.C. Escher

  4. #49
    Quote Originally Posted by cra View Post
    Hoe werd dan de relatie tussen de Business Objects en de GUI?
    Is dit dan met een IInterface (IObserver)
    Of hoe kan een wijziging van een property van mijn class doorsturen aan een Form?
    Wat je wilt. Je kan daarvoor een MVC achtige opbouw voor maken. Je kan ook je BO's op een TDataSet laten baseren en Delphi's TDBEdit's er voor gebruiken. Of je doet een combinatie van beide en je maakt je eigen TBOEdit die je direct kan koppelen aan je business objects.
    We adore chaos because we like to restore order - M.C. Escher

  5. #50
    Meestal start men met een business-Model, dat kan bijvoorbeeld UML of iets anders zijn. Hierin worden alle tabellen en hun relaties opgeslagen.

    Van hieruit wordt het BO-model gegenereerd: de tabellen in de databank met eventueel triggers en stored procedures en de code/parameterisatie van het framework.

    Belangrijke zaken ( zoals extra telefoonnummers ) worden op deze manier op een veel gestructureerdere ( en nettere ) manier afgehandeld.

    Tools waar je on the fly je metadata aan kunt passen
    Als werkt met een relationele databank, dan wordt de aanmaak van extra tabellen, ondermeer door de security, @runtime niet zo eenvoudig als in Access en komen deze een stuk minder voor, designers e.d. natuurlijk buiten beschouwing gelaten

    Als je dat niet weet en je nog flexibeler wilt zijn kan je je BO's en je DA's ook gewoon extra velden laten invoegen.
    Ik denk dat je hiermee de streamers bedoeld? Extra in de BO's aangemaakte structuren ( zoals memdata-sets e.a. ) worden hierbij als een Blob in een tabel weggeschreven. Enorm handig en enorm flexibel zolang deze een uitzondering blijven en niet een regel, want ze zijn een ideale manier om je complete project in een totale chaos te laten ontaarden.
    Last edited by rik.osstyn; 06-Dec-07 at 22:11.
    De verbazing begint waar de kennis ophoudt

  6. #51
    worden op deze manier op een veel gestructureerdere ( en nettere ) manier afgehandeld.
    Ik ben je weer eens kwijt.

    Hoezo / waarom?

  7. #52
    Wat ik bedoel is het volgende: Alhoewel dat het perfect mogelijk is om dergelijke zaken @runtime te doen, is het toch een stuk gestructureerder ( maar wel wat meer werk ) om je business model aan te passen en alles in design-time aan te passen.

    Ik ken veel database-systemen waar de data zo'n beetje overal rondslingert. Ik ben er niet per definitie tegen, maar ik zie het een beetje zoals het gebruik van Memo-velden: deze zijn goed en flexibel, maar op de lange duur geraken ze er ook telefoonnummers en adressen in kwijt.

    Runtime-velden en memo's zie ik als een ( heel handige ) noodoplossing, maar het mag geen systeem worden, anders wordt het de hoogste tijd dat je je datastructuren eens gaat nazien.
    Last edited by rik.osstyn; 06-Dec-07 at 22:27.
    De verbazing begint waar de kennis ophoudt

  8. #53
    zeg dat dan meteen

    Ik ben het overigens op dit punt met je eens, al is het soms functioneel handig of nodig om het @runtime te kunnen doen. Ook dat is best gestructureerd aan te pakken natuurlijk.

    Maar zoals in een eerdere post gezegd, vooraf goed nadenken over je datamodel loont. Ik hoef zelden mijn metadata aan te passen, tenzij uiteraard de functionaliteit wijzigt of uitgebreid moet worden.

    Ik voel overigens een split aankomen, want dit is wel een zwabber thread aan het worden volgens mij. Database ontwerp of je model staan natuurlijk los van hoe je je business laag gaat implementeren, of dat nu een OPF is, of een oplossing met datasets, of een combi van die 2 of gewoon een kaartenbak

  9. #54
    senior member PeterVercruysse's Avatar
    Join Date
    Nov 2006
    Location
    Rijsel
    Posts
    1,608
    Database ontwerp of je model staan natuurlijk los van hoe je je business laag gaat implementeren
    Ja en neen zou ik zeggen.

    In een klassiek model staat een Business Model volledig los van de programmatuur. In een BO-model bestaat er een veel groter affiniteit tussen beiden, in sommige gevallen zijn deze zelfs geïntegreerd.
    Gras groeit niet sneller door er aan te trekken

  10. #55
    In een BO-model bestaat er een veel groter affiniteit tussen beiden, in sommige gevallen zijn deze zelfs geïntegreerd.
    Dat weet ik niet. Ik ben een dataset man, al lult mijn client tegen services aan op de app server.

    Maar ik heb zeker geen 1 op 1 koppeling tussen mijn database en bv mijn gui.

    Ik zou er denk ik ook niet vrolijk van worden als het te strak aan de database vast hangt omdat je dan volgens mij nogal wat moet aanpassen als je datamodel wijzigt (of je database).

  11. #56
    senior member PeterVercruysse's Avatar
    Join Date
    Nov 2006
    Location
    Rijsel
    Posts
    1,608
    De ironie van het verhaal is meestal zo dat waar de BO-modellen oorspronkelijk ontwikkeld waren om onafhankelijk te draaien van de databases, het in de praktijk meestal net andersom is, omdat het BM, de database en het BO-framework nogal sterk gerelateerd zijn.

    Gebruik je trouwens een BO-model, Benno? Persoonlijk denk ik om zeker die richting uit te gaan.

    @ Handsaeme: Ik zal nazien om een klein voorbeeldje samen te stellen. Het is misschien ook interessant voor de anderen.
    Gras groeit niet sneller door er aan te trekken

  12. #57
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Ik heb het gedaan bij een vorige werkgever (niet door mij opgezet).

    PO-CO-BO-DA abstractie laag. (PO=presentatie, CO waren "controllers", de schakel klasses die alles op een behoorlijk hoog niveau instrumenteerden.

    Typisch dus PO-voor input, dan BO voor processing en dan weer PO voor uitvoer. PO was ook invoer omdat het een websysteem was, en dat subsysteem had contact met de webserver voor sessie data enz. De CO benaderde nooit de DA laag rechtstreeks.

    De basis BO was in principe OO en los van de DA laag en datasets, maar er werd in sommige delen (vooral de nightly maintenance en rapport generatie) ook wel eens met datasets gewerkt. Het aantal tabellen liep tegen de duizend aan. Het E-R diagram werd op meerdere A2's geprint en aan elkaar geplakt als een poster.

    De CO laag had wel nog een soort hoog niveau transactie support (read transactie of write transactie). Een CO routine zag er typisch zo uit:

    Code:
      haal data uit PO laag en sessie
      start transactie r/w
      obj:=bo.getdata;   // kunnen ook lijsten zijn.
      <verwerk data>
      bo.updateX
      bo.updateY
      eind transactie
      presentatie laag.
      einde van sessie
    De BO was een mengeling van direct op tabellen en joins gemapte objecten, maar ook met daar over heen gelegde totaal geabstraheerde logica. Van alle lagen werden de diepere delen automatisch gegenereerd. De joins en andere combinatie objecten werden abstract in een GUI programma vastgelegd, wat metadata was voor de generator. Hier zaten b.v. ook vlaggen bij of nieuwe velden in de tabellen aan een samengesteld objecten toegevoegd moesten worden, of niet. De generator genereerde daarnaast een hoop warnings, hints e.d. wat belangrijk was voor de integriteit van het systeem.

    Een object kon daardoor b.v. gedumpt worden in de context van de presentatie laag, waar de template engine de velden in het template van de webpage verwerkte.

    In de hoogtij dagen zaten er 10 mensen op het project, waarvan 6 programmeurs. Ik was in praktijk opvolger van de originele architect van het framework en deed vn framework onderhoud en uitbreiding, de auto generator, profilen en optimalizatie (het hele systeem was synchroon. Onder geen enkele voorwaarde mocht de klant gecached data zien die niet strookte met de database inhoud. Met name vanwege het risico dat hetzelfde object/partij aan meerdere bedrijven werd verkocht) en de meer losse onderdelen (veel indy gebruik, hetgeen ook de reden was dat ik werd aangenomen. Het was toen nog niet bekend dat de originele architect wegging).

    De optimalizatie moet je overigens voor het kern systeem voor een groot deel niet zien in het licht van mijn normale posts hier. Dit was een systeem met een (SQL Server) database, dus dat was altijd de bottleneck. De grote winsten werden behaald door identificeren van data die in een bepaald deel van het business model invariant was. Dat werd vervolgens uitgebuit door caching van data die b.v. maar 2 x jaar geupdate werd onder strikte voorwaarden, en vooral gebruik van modifiers als no_lock, beperken van roundtrips, verwijdering van temptables )

    Het basis object was in principe een tstringlist van velddefinitie classes met een dynamische array van variants voor de waarde. (NULLABLE!). De Delphi code maakte mij aan het huilen uit performance perspectief, streamen op string basis, variants, enorme lagen met methods die niet veel deden dan 1 of 2 andere methods aanroepen, excepties galore enz. Maar profilen wees het maar zelden als de bottleneck aan. (zwaardere transacties bevatten soms een miljoen een stringoperaties)

    Profilen deed ik meestal op basis van het framework (support voor timen van de acties en voor aantal queries op de lijn in het framework), minder met SQL Server profiling tools. Een collega was daar ook handiger in.

    Over de exacte reden daarvan verschilde de meningen, maar toch kwamen ze op het zelfde neer. Volgens mijn collega's was Delphi code oneindig snel, volgens mij was de database oneindig traag :-)

  13. #58
    Gebruik je trouwens een BO-model, Benno?
    Geen idee. Als je een opf achtig iets bedoeld dan is het antwoord nee.

    Ik werk met kbmMW (www.components4developers.com) die zelf is opgebouwd met services aan de server kant. Die services kunnen naar de database, of bijvoorbeeld andere services (desnoods op een andere server) aanroepen. Daarbij werk ik eigenlijk (bijna) altijd stateless op die servers.

    Ik probeer mijn services daarbij zo op te zetten dat het een logisch geheel is, bijvoorbeeld factuurinfo bij elkaar, contacten bij elkaar enz. Een factuurservice kan zo bijvoorbeeld ook gebruik moeten maken van de contactpersonen. Een order zal zo bv de ordermodule aanroepen, maar vanaf daar ook bv de voorraad bijwerken (die meestal op een andere service zal staan).

    Ik probeer zoveel mogelijk database zaken daar op te lossen. Zou mijn tabel structuur wijzigen bv of een andere database eronder moeten, dan is dat de enige plek die ik aan moet passen.

    Mijn client heeft meestal een algemene datamodule die de connectie bevat en zaken als de lookup tabellen. Voor die lookuptabellen heb ik een mechanisme met messaging. Een wijziging van een lookuptabel (op de server) zal resulteren in een message (asynchrone thread) naar alle clients. De eerstvolgende keer dat ik een bepaalde lookup nodig heb zal die ververst worden als er wijzigingen waren.

    Mijn GUI heeft meestal per scherm een datamodule. Die datamodule veegt de info bij elkaar uit de diverse services en toont ze (en geeft edit mogelijkheden e.d.). Bij het opslaan zal aan de serverkant de data worden gevalideerd en komt een melding retour bij een fout (een exception op de server die via een mechanisme op de client uitkomt). Op basis daarvan kan een klant dan zijn info aanpassen.

    Sommige klanten willen echter meteen een controle op het moment dat ze bv een veld verlaten. In dat geval zitten de controles aan de client kant. Niet de meest optimale oplossing (eigenlijk wil ik alleen weergave en invoer op de client), maar daar heb ik nog geen handige generieke oplossing voor gevonden.

  14. #59
    Quote Originally Posted by rik.osstyn View Post
    Runtime-velden en memo's zie ik als een ( heel handige ) noodoplossing, maar het mag geen systeem worden, anders wordt het de hoogste tijd dat je je datastructuren eens gaat nazien.
    Als je je product maar voor 1 klant maakt heb je helemaal gelijk. Als het voor meerdere klanten is en bijna allemaal willen ze het zelfde heb je helemaal gelijk. 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.
    We adore chaos because we like to restore order - M.C. Escher

  15. #60
    Quote Originally Posted by Benno View Post
    Sommige klanten willen echter meteen een controle op het moment dat ze bv een veld verlaten. In dat geval zitten de controles aan de client kant. Niet de meest optimale oplossing (eigenlijk wil ik alleen weergave en invoer op de client), maar daar heb ik nog geen handige generieke oplossing voor gevonden.
    Dat zou kunnen als je de server weer zou aanroepen voor de validatie. Of je gedeeltes van je BO ook op de client beschikbaar hebt (zonder ze in de GUI te mengen).
    We adore chaos because we like to restore order - M.C. Escher

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