Delphiben kódolt Database program

Delphiben kódolt Database program
2008-01-18T23:38:03+01:00
2008-01-21T00:09:06+01:00
2022-10-30T02:15:32+02:00
  • Mutasd a teljes hozzászólást!
  • Valhogy így kell ezt megvalósítani:

    --- KÓD ---

    Ezen a szinten egy büdös gombod sincs, szimplán osztályokba rajzolt adatok, és az ezt kezelni képes programkód.

    - Adat: Vannak az adatok. Mittomén, a felhasználók, raktárkészlet, akármi. Ezek egyrészt ott figyelnek egy adatbázisban vagy fileokban, másrészt reprezentálva vannak Pascal osztályokban. A reprezentációs osztályokba csak olyan kódot szabad tenni, amik magáért az adattulajdonságok kezelésért felelősek. Például képesek megmondani, hogy az bennük lévő értékek helyesek-e (egy ember nem lehet 1500 kg, stb).

    - Adatelérés: Azokat a kódokat kell idetenni, ami azért felelnek, hogy a reprezentációs osztályokat elő lehessen állítani az adatbázisban tárolt értékek alapján (query), ezeket oda le lehessen menteni, lehessen frissíteni, stb. Kinaiul ez a DAL réteg.

    (Még mindig nincs gombod sehol, de a nyers adatokat már itt tudod kezelni - kódból.)

    - Üzleti logika: Idióta név, angolul jobban hangzik (bizniszlodzsik). Itt valósítod meg a programod működését. Logikailag, egy büdös OK gomb nélkül. Osztályok, metódusok, amik minden feladatot elvégeznek, amit a programodnak tudni kell az adatelérési és az adotmodell rétegre támaszkodva. Például egy UserManagemet osztály, aminek a metóduskészletével képes vagy tökéletesen kezelni a programod felhasználóit. Egy RoleManagement osztály, amivel teljes mértékben képes vagy kezelni a UserManagement által felvitt felhasználók jogait az alkalmazásodban. Egy olyan osztály vagy osztályegyüttes, aminek metódusaival és tulajdonságainak állapotaival (egy megveszekedett OK gomb nélkül) képes vagy menedzselni a teljes raktárkészletedet olyan szinten, hogy itt kezeled, hogy pl egyáltalán létezik-e olyan árutípus vagy mennyiség, amivel a porgramod foglalkozni akar.

    (Ha idáig eljutsz, és el kellett indítani a From designert, vagy akár egy darab dialógusablakot megjelenítő sort is írtál, akkor nem jutottál el idáig, mert az úgy nem fog működni értelmesen. Hogyan lehet akkor felületek nélkül tesztelni a modulokat? Unit teszt. Rosszabb esetben konzol. A lényeg, hogy a prezentáció itt még nem van, bár fejben látni kell ahhoz, hogy az üzleti logika megfelelően működjön = korrekt tervezés, papír, ceruza, 5 kilo radír!)

    --- Felület ---

    Itt most már csak azt kell megoldani, hogy az üzleti logika (láthatatlan) funkcionalítását, és az adatok (szintén láthatatlan) reprezentációját megold. Elő lehet venni a designereket. Innentől kezdve adja magát, hogy nincs szükség ezer ablakra, modális, böhömnagy beviteli formokra, hiszen a szépen szeparált kódréteged működik, akárhogyan is jeleníted meg. Nem fog fejfájást okozni az, hogy van egy főablak, ami szét van osztva, és egy user módosítására bejön jobbra egy tool felület, ahol megjelennek az user adatok, hiszen nem a felület fogja menedzselni az usert, hanem az üzleti logikád, nem lesz az egész egy teljesen átláthatatlan, formokba gányolt kódhalmaz, amit rajtad kívül még maga a jó Isten sem lesz képes átlátni, és te is csak a jövőhét szerdáig tudod, hogy melyik form kódjában mi van.

    Ezt a mókát úgy hívják kinaiul, hogy MVC Design Pattern. Ajánlom minden Delphi fejlesztő figyelmébe, mert sajnos a VCL koncepciója minden, csak nem MVC (bár ki lehet vele vitelezni elég könnyen).
    Mutasd a teljes hozzászólást!

  • Köszönet
    Mutasd a teljes hozzászólást!
  • Hát nézz körül! Nem nehéz észrevenni, hogy mi az irány. Szépen egy ablakba pakolt/dokkolt user interfész a jellemző manapság, amit a felhasználó kedvére testre szabhat. Már a modális ablakokkal sem nagyon zaklatják a felhasználókat (kivéve a pici dialoógusokat), hanem szép, letisztult, bedokkolt eszközablakokat tesznek az orruk elé. Jó példa ide a PhotoShop. Egészen a CS2-ig ragaszkodtak ehhez az idióta MDI-s agyrémhez, de aztán felvettek valakit, aki értett is a dolgához, és a CS3 felhasználói felületét a nulláról újra írták, mindenki nagy megelégedésére. Aztán ott van az Office 2007 és a ribbon vezérlők. Maga a Delphi is leszokott arról a hülye szokásáról, hogy szanaszét szemetelje a desktopot az ablakaival, minden szépen ott figyel a helyén az egyetlen ablakban.

    Egy ablak mind felett, egy ablak az egyetlen!

    A fejlesztési módszerhez van egy idézetem: "Think big, start small!"
    Mutasd a teljes hozzászólást!
  • Az UML azért jött ide mert rosszul írtam amit akartam Nem jutott eszembe a szoftver neve amivel a múltkor összeakadtam szörfölés közben. Csak arra emlékeztem, hogy egy komlex fejlesztőeszköz az UML-től a kódoláson át. Visszakerestem, ez a "Visual Paradigm" volt. Software Design Tools for Agile Teams, with UML, BPMN and More

    Az XP-t meg olvasgatom, köszi az infót.

    Az eredeti kérdésre mégis te melyik mellett voksolnál? MDI<>SDI
    Netalán fej vagy írás alapon döntsek?

    Mutasd a teljes hozzászólást!
  • Nem értem, az UML hogyan jött most elő de én speciel szeretem szigorúan csak arra használni, amire való: egy rendszernek vagy egy részének vázlatos ábrázolsára specifikációban vagy rendszerdoksiban.
    Ez a mindent részletesen megtervezünk UML-ben aztán kódolunk majd tesztelünk elv már régóta haldoklik, mert ezzel a módszerrel egyszerűen nem lehet a jellemzően folyamatosan változó követelményeknek megfelelően továbbfejleszthető vagy teljesen átalakítható szoftvereket fejleszteni.

    Persze a gyakorlatban a fejlesztők nagy része hadakozik, mikor az alapjaiban kell megváltoztatni egy még el sem készült rendszert, mert megváltoztak a követelmények. Ők még ezeket a régi (vízesés modell) elveket tanulták.

    Szóval ha nem élő kövületként akarsz indulni a szakmában, érdemes az agilis módszerek tájékán körülnézni. Ilyen pl. az Extreme Programming
    Mutasd a teljes hozzászólást!
  • Segít, de akkor manapság mit preferáltok? Valamilyen UML Developer, ami egészen a tervezéstől a kódoláson át mindent megold egy szoftver segítségével?
    Mutasd a teljes hozzászólást!
  • Ha ez segít, az MDI halott.
    Már MS sem erőlteti, a felhasználók többsége meg kifejezetten utálja, mert nekik átláthatatlan.
    Mutasd a teljes hozzászólást!
  • Üdvözlöm a Listát!

    Meglehetősen kezdő vagyok. Talán közepes szinten ismerem a Delphit, az adatbázistervezést stb. Egyre inkább látom, hogy a tudásom mennyire kevés, mennyi mindent nem tudok még.
    A konkrét problémám az, hogy egy adatbáziskezelő szoftvert fejlesztek. Ez az első programom. Tizenpár táblával. Azt fontolgatom, hogy MDI legyen az elkészülő alkalmazás. Viszont kételyeim vannak, majd nem okoz e valamilyen hivatkozási problémát a későbbiekben , DataAccess, DataControls, stb. komponensek kezelése. Lesznek olyan formjaim,(mindegyik) melyeket Childként szeretnék indítani, de csak egyszerre 1 példány futhasson,de futhasson egy időben több child is. Ezt úgy valósítanám meg, hogy override diráktívával új classt hoznák létre. Nem szeretnék bemenni az erdőbe, és sok munka után rájönni, hogy valamilyen adattáblát nem tudok módosítani stb., ha dinamikus formokat használok. Hogyan szoktátok ezt megoldani? Legyen inkább SDI? Köszönet
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd