Results 1 to 10 of 10

Thread: Business Objects: mijn eigen ontwerp.

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

    Business Objects: mijn eigen ontwerp.

    Al een tijdje ben ik gefascineerd in het MVC model. Wat is mooier dan een duidelijk scheiding tussen data en view. Zo zijn er verschillende tools in omloop. Een greep daarvan:
    Commercieel
    1. KbMMW (http://www.components4developers.com)
    2. EntiyDAC (https://www.devart.com/dac.html)
    3. TMS Aurelius (https://www.tmssoftware.com/site/aurelius.asp)

    Opensource
    1. Tiopf (http://tiopf.sourceforge.net/)
    2. Mormot (https://synopse.info/fossil/wiki/Synopse+OpenSource)
    3. xmm (stijn sanders / develyoy)
    4. MVVM framework
    5. livebindings (alleen delphi)
    6. DBRoot

    Met een aantal heb ik geprobeerd mee te spelen. Maar je heel veel geduld en studie-uren nodig om het goed voor elkaar te krijgen. En nog lukt het niet. Jezelf een week opsluiten in een huisje zal kunnen wekren met veel geduld, goede documentatie en het alle belangrijkste: INTERNET.

    Het doel is geheel logisch. Laat een object het werk doen en geef alleen weer wat je wilt zien. Dus niet componenten aansturen vanuit de form, maar de controller vertellen wat hij moet visualseren naar het scherm toe. Voordeel: Je scherm bevalt qua inhoud / view niet meer en doordat je alleen maar visuele componenten gebruikt, is het makkelijk om een ander scherm aan te maken of je wilt overgaan op een ander dialect zoals FMX.

    Maar goed. Veel studie dus. Maar ik ben eigenwijs en wil het zelf in elkaar knopen om te snappen wat er eigenlijk gebeurt. Na een aantal artikelen te hebben gelezen en te hebben gespeeld met wat tools dacht ik bij mij zelf : Hoe moeilijk kan het zijn?. Antwoord: niet makkelijk. Maar ben er voorzichtig aan begonnen.

    Wat is mijn doel?
    Wij hebben op ons werk een excel document, waarin voor ons instaat op welke datum een verkooporder naar een klant wat met aanvullende informatie. Nadeel: 1 PERSOON KAN WIJZIGEN. Moet anders kunnen.
    Mijn eerste basis was een export te maken van het document en kijken hoe ik dat kan visualiseren met MVC.
    Vanuit de import heb ik controllers gemaakt om het dataverkeer met de componenten goed te laten communiceren. Als de data is ingelezen, kan ik het 'record' ophalen en bewerken en zelfs opslaan. Het resultaat staat in de bijlage.

    Mijn volgende doel is het maken van een nieuw 'record'.

    Commentaar is altijd welkom.

    Wordt vervolgd......
    Attached Files Attached Files
    Delphi is great. Lazarus is more powerfull

  2. #2
    Het voordeel van KBMMW het niet alleen ORM heeft, maar dat dit ook nog client-server werkt. Je kunt dan heel gemakkelijk in de client een functie aanroepen en je krijgt direct een object(list) terug van de server. Dit kan in een native formaat of in REST/JSON. Het nadeel op dit moment is dat dat je de entity objecten wel zelf moet schrijven/mappen, iets dat volgens mij in de andere twee (semi) automatisch gebeurd. Ook kun je van object list naar een dataset, dus je kunt gewoon data aware componenten blijven gebruiken. Ik heb zelf op deze manier een tijdje geleden een REST servertje gemaakt en het werkt echt heel simpel met bijzonder weinig code.

    Voor mijn huidige project had ik geen tijd/zin om halverwege de hele aanpak te wijzigen, maar het is beslist iets dat ik ga onderzoeken voor toekomstige projecten. Het lijkt me zoveel makkelijker om een TPerson terug te krijgen dan een dataset.

  3. #3
    John je gooit in je lijstjes ook zaken door elkaar. Soa frameworks zoals kbmmw, mormot e.d hebben niks met mvc te maken. MVVM is ook een hele andere aanpak dan mvc. Voor mij als delphi dev trekt mvvm me veel meer dan bv mvc. MVC in delphi vindt ik persoonlijk een crime en volledig tegennatuurlijk als je op de rad manier werkt.

    Frameworks als kbmmw zijn juist heel krachtig om functionaliteit in services via een api beschikbaar te maken. Meestal doe je dat stateless.

    Aan de front end kant consumeer je die diensten. Hoe je dat bouwt maakt niet zoveel uit, maar dat is naar mijn mening de plek waar je zaken als mvvm of mvc gaat toepassen.

    In jouw concrete voorbeeld begin je naar mijn mening al met een ontwerpfout. Een excel document voor visualisatie is prima. Een excel document als invoer is een ontwerpfout tenzij je af kunt dwingen dat er maar 1 versie van bestaat. Als je collega's perse excel willen gebruiken zou je nog een plugin kunnen maken die zorgt dat het fatsoenlijk (toepassen ban business rules en versioning) in een database gaat.

  4. #4
    Het nadeel op dit moment is dat dat je de entity objecten wel zelf moet schrijven/mappen, iets dat volgens mij in de andere twee (semi) automatisch gebeurd.
    Ook daar is kbmmw best flexibel.

    Kim is een groot voorstander van definieren van objecten in code, het opslaan naar een db is al geautomatiseerd. Is wat voor te zeggen, vooral omdat kbmmw heel makkelijk meerdere versies van dezelfde service kan draaien, waarbij de client kan kiezen voor een service versie.

    Maar ook mappen naar objecten vanuit datasets kan vrij makkelijk. Je kunt dus als je dat wilt op de oude manier met datasets blijven werken op de server en dat via een rest interface beschikbaar maken in json. Ik sleutel al een poosje aan een product die onder andere dat gebruikt om databases (of andere backends) makkelijk beschikbaar te krijgen op een rest interface.

  5. #5
    Ook daar is kbmmw best flexibel.
    Maar er is geen andere manier toch dan zelf definiëren?

    In mijn geval begon ik met een bestaande database en heb ik de "kbmmw" objecten zelf geschreven. Waarschijnlijk is het sneller om de objecten te schrijven en de database te laten genereren.

  6. #6
    Maar er is geen andere manier toch dan zelf definiëren?
    het is maar net hoe je objecten ziet. Een dataset of groep van datasets kun je makkelijk via de field properties serializen naar json objecten met generieke code. Vanuit je client gezien heb je dan dus gewoon objecten, op de server werk je op de "ouderwetse" dataset manier.

  7. #7
    Dat is natuurlijk ook een manier. Ik zat bij objecten hier aan te denken.

  8. #8
    Senior Member
    Join Date
    Dec 2003
    Location
    Den Haag
    Posts
    190
    Model-GUI-Mediator is ook een optie. Ik ben zelf gecharmeerd van.

    Graeme Geldenhuys heeft goed artikel geschreven over Model-GUI-Mediator pattern
    http://geldenhuys.co.uk/articles/

    Andy Bulka ook.
    http://www.andypatterns.com/index.ph...ad_file/51/46/

    Ik heb op het ogenblik weinig tijd om MGM op je voorbeeld toe te passen. Maar als je aan de slag gaat en vragen hebt, stel ze gerust.

  9. #9
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,325
    Quote Originally Posted by Benno
    Een excel document als invoer is een ontwerpfout tenzij je af kunt dwingen dat er maar 1 versie van bestaat
    Ik heb puur de import van het excel nu gedaan, omdat ik gewoon met een basis wil werken omtrent gegevens structuur. Waar het mij omgaat is de basis. Wordt deze goed gelegd met de communicatie tussen componenten en objecten goed gelegd.
    Quote Originally Posted by Erwin
    Graeme Geldenhuys heeft goed artikel geschreven over Model-GUI-Mediator pattern
    Dat weet ik. Heb TiOPF ook hier op mijn laptop. Daar weet ik ongeveer hoe hij de communicatie regelt tussen data en view.
    Quote Originally Posted by Benno
    John je gooit in je lijstjes ook zaken door elkaar. Soa frameworks zoals kbmmw, mormot e.d hebben niks met mvc te maken.
    Uiteindelijk hebben al deze tools één doel. Data gescheiden houden van de view en alleen tonen wat noodzakelijk is.
    Last edited by jkuiper; Yesterday at 08:49.
    Delphi is great. Lazarus is more powerfull

  10. #10
    Ik denk bij business objects in de eerste plaats aan business- en domeinlogica. Dat speelt zich volgens mij helemaal af binnen de M van MVC (of de eerste M van MVVM). De UI en de opslag (inclusief datasetjes en/of REST communicatie) staan daar volgens mij helemaal of in ieder geval grotendeels buiten. Dat hele lijstje van 9 tools uit de eerste post lijkt me irrelevant als je over business objects praat. Je kan beargumenteren dat een business object überhaupt niets over opslag hoeft te weten, maar zelfs als het dat wel doet, dan toch hopelijk in ieder geval zo ver geabstraheerd dat het vanuit het BO niet uitmaakt welk ORM framework er gebruikt wordt.
    1+1=b

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (1 members and 1 guests)

  1. Erikske

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
  •