Delphi-ről C++-ra váltás
2010-08-19T13:12:44+02:00
2010-09-01T13:20:05+02:00
2022-07-25T00:07:21+02:00
  • A lényeg, hogy felejtsd el a C++ t és nyomd a .NET-et.
    Mutasd a teljes hozzászólást!
  • Hmmm... Na ilyenkor érzi magát hülyének az ember
    Mutasd a teljes hozzászólást!
  • Teljesen nem lehet megoldani a DRY problémáját, bár azért lehet ügyeskedni. Pl. egy objektumon egy ellenőrző kód futhat a kliens és a szerver oldalon is. De akár azt is megteheted hogy csinálsz egy szervizosztályt ami megkap egy vagy több üzleti objektumot és csinál vele különféle dolgokat - és dll-ként szintén ott lehet mindkét oldalon.

    Anno én is csináltam ilyet úgy 15 éve házi használatra. Az mondjuk még Delphi forráskódot generált, de elvben tudott volna Pl. javársat is. Még saját programnyelve is volt. Szépen meg is csinálta az automatizálható CRUD-os formokat, úgy ahogy kell. Csak amikor aztán elkezdtem élesben használni, rájöttem hogy megírja ugyan a kódnak úgy a 10%-át amire ezt a sémát rá lehet húzni, de a többit ugyanúgy kézzel kellett megírni. A legtöbb ügyviteli formnak picit többet kell tudnia produkálni mint egy egyszerű CRUD.
    Mutasd a teljes hozzászólást!
  • Ez egy nagyon mély és nehéz probléma, mert van itt két design szempont, ami egymás ellen dolgozik:

    Ha erősen rétegezed az alkalmazásodat (legalábbis azokkal a módszerkkel, ahogy ezt ma 2010-ben szokás), akkor óhatalanul sérted a DRY principle-t: (Don't Repeat Yourself) és 'accidential complexity'-t vezetsz be, és növeled a fejlesztés költségét. Ez egyes komplex alkalmazásoknál elkerülhetetlen, de egyszerűbbeknél nagyon csökkenti a versenyképességet. És mi az egyszerű alkalmazás? Ez sem teljesen tiszta; minél fejlettebb technológiáink vannak, annál komolyabb alkalmazások minősülnek 'egyszerű'-nek.

    Pl. ha van egy tipikus CRUD karbantartó felhasználói felületed, akkor te mint programozó legszívesebben csak annyit akarnál mondani, hogy a név-mező max 32 karakteres legyen. Az, hogy ezt Javascriptben ellenőrizni kell, hogy a szerver oldalon is ellenőrizni kell, hogy milyen hibaüzenetet kell konstruálni, ha nem jót írt be a delikvens, hogy a css-ét át kellene írni hogy bepirosodjon, ha rosszat írtak bele, hogy a html edit field mérete igazodjon a maximum karaktermennyiséghez, hogy az adatbázisban ez a tábla VARCHAR(32) legyen, stb..., az miért érdekeljen engem? Oldja meg egy framewörk. Sőt, engem az sem érdekel, hogy Javascript meg css meg html van a kliensen. Oldja meg egy framewörk, hogy működjön ugyanez delphis, QT-t vagy akármilyen klienssel ugyanazt a felhasználói élményt nyújtva. Legyenek generikusan megírt stylesheetek ha a különféle megjelenítést szerető embereknek. Ha ilyen technológiákat használunk, akkor viszont felmerül a kérdés, hogy miért is olyan fontos a felhasználói felület kódját leválasztani az üzleti logikától? Hiszen így szinte nem marad semmi alkalmazás specifikus 'felhasználói felület kód', ami marad, az meg olyan maas szintű, hogy valamilyen értelemben az is 'üzleti logika': nem függ attól, hogy javascript vagy qt vagy mi a megjelenítő kód. (Üzleti logika az, hogy a név mezőbe maximum 32 karakter kerülhet? De még mennyire!!!)

    Szóval eyszerűbb esetekben a versenyképesség szempontjából kifejezetten hátrányos a túlzott rétegezés. Ezt persze felismerték sokan, és jelenleg úgy próbálják megoldani (pl. Naked Objects), hogy az alkalmazás sok részén alapvetően csak egy réteg van, egy réteget ír a programozó, a többi meg generálódik: logikai szempontból a generált kód nemlétező kód, ha létezőnek tekintenénk, akkor állandóan a bele kellene számolni a képbe a közbülső formátumokat: java bytecode, LLVM, gépikód meg még kitudja mi van egy JIT-elt architektúrában.

    (Mondanom sem kell, hogy én is azon dolgozom, hogy egyszerűbb, alapvetően CRUD jellegű alkalmazásokat hogyan lehet a lehető legkevesebb, és a userek számára a lehető legintuitívebb információkból létrehozni. Természetesen abban a kognitív modellben, amiben a cuccomat használni fogják, csak egy réteg lesz, (persze stylesheetek lesznek).)

    A rétegezés másik problémája, hogy sokszor a performancia ellen megy, de erről már beszéltetek, és ez talán másodlagos szempont egy egyszerű alkalmazásnál általában.
    Mutasd a teljes hozzászólást!
  • Saját tapasztalatom alapján kisebb ügyviteli programoknál teljesen rendben van, ha mindent kliens oldalra teszünk.

    Az már nagyon kisebb ügyviteli rendszer az ahol ez rendben van.
    Mutasd a teljes hozzászólást!
  • Saját tapasztalatom alapján kisebb ügyviteli programoknál teljesen rendben van, ha mindent kliens oldalra teszünk.

    Vállalati környezetben viszont az elég gáz tud lenni, ha millió rekordok mennek át kliens oldalra pl. egy másik földrészről VPN-en.

    Ebben a szakmában mindennek megvan a maga alkalmazási területe. Szerintem nem szabad hinni azoknak, akik mindenre ugyanazt a megoldást javasolják.
    Mutasd a teljes hozzászólást!
  • Az hogy az üzleti logika le van választva az UI-tól ma már eléggé magától érthetődő. De az RDBMS, az üzleti logika és az UI három szint. Sőt, az első kettő közé még kerülhet egy data access layer is, bár erre már vannak ORM-ek amik elég jól kiváltják a dolgot.
    Mutasd a teljes hozzászólást!
  • Ez is igaz. Máshogy közelítem meg. Jelenleg nem ismerek más technikát. És abban tényleg jó, hogy gyorsabb, mert csak egyszer kell felépíteni a kapcsolatot, egy utasítást elküldeni, majd a visszatérő eredményre reagálni. De célom fejlődni a jövőben.
    Érdekes, de eddig azt hittem, hogy ha áttérek tárolt eljárásokra, jól teszem. Eléggé megingattál:)

    Van egy másik szempontom is. Magam részéről jobban átlátom a kódot, külön van választva a szerveren és a fejlesztő alkalmazásban a két kód.
    Persze a kisebb dolgokat azért szimplán kezeljük.
    Mutasd a teljes hozzászólást!
  • Minek egy tárolt eljárást ennyi féle felületről hívogatni ? Annál is inkább, mert egy komolyabb alkalmazás esetén az UI-ban lévő kód is elég lényeges (Pl. validálás), ezt meg elég gáz ha külön meg kell írni Delphiben és C++-ban is. Hacsak nincs kórosan sok szabadidőd.
    Mutasd a teljes hozzászólást!
  • mellette szól, hogy ugyanazt a tárolt eljárást hívom meg php, delphi, c++ alatt. Ha valami ötletem támad, elég a t.e.-t módosítani, nem kell sok gépen végigmenni. Léteznek jobb megoldások, mint amit ma használok, de az egészét tekintve jobb választás Delphi, C++ (Qt).
    Mutasd a teljes hozzászólást!
  • A tárolt eljárásban való adatbáziskezelés elég nagy önszopatás. Alapjában véve két dolog szól a dolog ellen, és egy mellette.

    Az az egy dolog a sebesség.

    Ami viszont ellene szól, az egyrészt az hogy az RDBMS-ek tárolt eljárásainak nyelve finoman szólva eléggé szutyok egy normális programnyelvhez képest. Ami nem csak azt jelenti hogy hogy bonyolultabb lesz a kódod, de azt is hogy áttekinthetetlenebb. Márpedig egy ügyviteli szoftnál azért az hogy jól számoljon lényegesebb szempont mint hogy gyorsan számoljon.

    A másik ami ellene szól az az hogy nincs egységes nyelve a tárolt eljárásoknak. Másképp kell programozni egy Oracle-t, másképp egy MS-SQL szervert, másképp egy Firebird-öt. Azaz ha sok tárolt eljárásod van az igencsak megdrágítja a más adatbázisszerverre való portolást.
    Mutasd a teljes hozzászólást!
  • Hiába írsz saját libet attól még nem lesz LINQ, meg RAD eszköz. Tárolt eljárás az még az ősi módszer. Most ott tartunk, hogy Entity Framework, meg CO. Olyan megoldások vannak, hogy entitások, state machine, automatic forms. Ezek túlmutatnak már rég azon, amire most készülsz, de még a Delphi-n is.
    Mutasd a teljes hozzászólást!
  • Mazochista vagyok
    Kicsit jó is lesz magamtól írni programokat.
    Idővel, ha már lesz elég saját library-m, class-om, csak gyorsabb lesz az

    Amúgy az adatbázis kezelés nagy részét tárolt eljárásban csináljuk.
    Mutasd a teljes hozzászólást!
  • Jóni jó, de a Delphi után ez nagy visszalépés lesz ügyvitel szempotjából. Nagyságrendekkel lasabban fogsz haladni. Cserébe nem feltétlenül lesz gyorsabb a programod, mivel a szűk keresztmetszet az adatbázis, meg esetleg a hálózat. Mindenesetre nem rossz, ha valaki szereti a külünös szakmai kihívásokat öncélúan gyűjteni.
    Mutasd a teljes hozzászólást!
  • No.

    Bevizsgáltam az összes lehetséges jelentkezőt, Qt lett a győztes.
    Minden szempontól ez tűnik a legjobb választásnak.

    Köszönöm mindenkinek a válaszokat, újabb szép, hosszú átprogramozott éjszakáknak nézek elébe...
    Mutasd a teljes hozzászólást!
  • Közben sikerült megoldanom. Be kellett importálni a csomagot...
    Mutasd a teljes hozzászólást!
  • Azért biztonsági tartaléknak ott a Delphi:)
    Attól nem félek, hogy ha hamar kell valamit csinálni...

    De mellette szépen lassan tanulgatom, fejlesztgetem magam C++-ban.
    Mutasd a teljes hozzászólást!
  • Hát igen... Még most gondold meg, hogy van e értelme C++ al komolyabb adatbázis kezelőt fejleszteni, mert ez csak a kezdet. Majd jön a memory leak, fragmentation stb. Sokat érsz vele, ha tudod mi megy a háttérben, ha soha nem készülsz el vele, vagy nagyságrendekkel tovább tart a fejlesztés. Jön egy másik fejlesztő, aki 2 nap alatt megcsinálja valamilyen komolyabb eszközzel azt, amivel te hetek óta szenvedsz és kirúgnak.
    Mutasd a teljes hozzászólást!
  • Ha tudnál, egy kis segítség jól jönne, mert próbálok megdolgozni egy mysql szervert, de a linkelés kiáll hibával. Elvileg az include és lib elérési útvonalak korrektek... De "unresolved external symbol"...:( Már a connectnél.
    Mutasd a teljes hozzászólást!
  • * a .NET-es implementációt nem én írtam
    Mutasd a teljes hozzászólást!
  • Igen, a lényeg a késztermék. De szeretnék közben fejlődni is. Annak idején Turbo Vision-nel hosszú kódsorokat gépeltem, és amikor a Delphi lerak egy gombot, tudom, hogy milyen kódsorok lehetnek a háttérben. Őrület, de szerettem a TV féle programozást. Azért egy kicsit lusta is vagyok, hogy osztályokat, library-ket írogassak:)
    Szeretném a C++-t alaposan megtanulni, nem mintha Delphi guru lennék, de ha már valamit ki akarok tanulni, az inkább C++.
    Jól jön ez még a jövőben:)
    Mutasd a teljes hozzászólást!
  • Jogos, de néha más elvárások vannak. Én például most fejezek be egy projektet, amit kifejezetten C++-ban kértek újraírni, mert a géppark nem bírta a .NET-es implementációt, viszont a program nem volt túl komplikált, úgyhogy olcsóbb volt újraíratni c++-ban, mint hardvert fejleszteni.
    Mutasd a teljes hozzászólást!
  • Ez utóbbi az ami miatt inkább C#-ot használok .NET-tel.

    Az első saját szakállamra fejlesztett ügyviteli programomat C++-ban csináltam wxWidgets-szel (amit 98-ban amikor kezdtem még wxWindowsnak hívtak). A másodikat már Delphi7/Kylix segítségével. A harmadik C#/.NET alapú. Pont azért mert a végeredmény a lényeg és nem az hogy az utolsó bitig én írjak meg mindent a nulláról.
    Mutasd a teljes hozzászólást!
  • Én továbbra is a Qt-ra szavaznék. Több okból:
    * A Nokia áll mögötte. Ha most Qt-ban kezdesz fejleszteni, szinte biztosra veheted, hogy 5, 10 év múlva is lesz Qt.
    * A Qt nagyon sokoldalú. GUI, XML, multimédia, hálózat stb. Szinte minden van benne, ami egy asztali programhoz kellhet.
    * A színfalak mögötti dolgok csak addig érdekesek, amíg nem tudod mi megy. Ha igen, akkor érdekesebb lenne, hogy határidőre elkészüljön a projekt.
    Mutasd a teljes hozzászólást!
  • Megnéztem ezt a U++-t. Tényleg bejött így első látásra. És pont, ahogy írva vagyon: látom, mi zajlik a színfalak mögött. Ilyen volt az elképzelésem.

    Próbálgatom még, remélem sikerül a nekem szükséges kódokat implementálnom.

    Gördülékenyebb, mint a DevC++, nem olyan macerás mint a Qt, (persze ez az én hibám), de miértne U++, ha tényleg olyan jó...!
    Mutasd a teljes hozzászólást!
  • Kezdeni érdemesebb ebből a dokumentumból.
    Ez eleve a layout tervezővel indít.

    Az általad linkelt oldal azzal kezd, hogy milyen egyszerű felületet C++ kódból is összehozni, ha a library rendesen meg van tervezve, majd a 16. fejezetben bemutatja, hogy a Layout-tervező ezt hogyan egyszerűsíti tovább. Gondolom azért, hogy értsd, mi zajlik a "színfalak" mögött.
    Mutasd a teljes hozzászólást!
  • Köhm, azért ettől még a wx is királyabb. Most ne már, hogy kézzel kell beirogatni mindent? Ez 2010-ben már nagyon kevés, de még 10 éve is az lett volna. Szerintem gépkódban írj ügyvitelt, úgyis 1, meg 0 pörög.
    Mutasd a teljes hozzászólást!
  • Az ilyen jellegű munkákra nekem ez a C++ fejlesztőkörnyezet jött be a legjobban.

    Ha tényleg tudsz és szeretsz is programozni, szerintem elképesztően jónak fogod találni. Delphiről tértem át én is, miután még kínlódtam vagy agy fél évet a wx-szel.

    Adatbázisos fejlesztésekhez teljesen más filozófiát követ, mint a Delphi, de már ilyenekre is ezt használom. Hosszabb távon kényelmesebb, hogy C++-ban definiálom az adatbázist is, a query-ket is és így már fordítási időben kijön, ha pl. egy tábla vagy mezőnevet elgépeltem.
    Mutasd a teljes hozzászólást!
  • Csak egy apróság.

    QT.

    Qt.

    Mutasd a teljes hozzászólást!
  • De persze ott van még a NetBeans is. Abba is belepislogtam, nem rossz az sem...
    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