[Javalist] Form & DB

Gábor Garami gabor.garami at hron.me
2013. Feb. 2., Szo, 23:50:02 CET 

A P/Invoke ott tud problemat okozni, ha nem csak hivogatni kell
dolgokat benne, hanem oda-vissza adtcsere is kell, raadasul
intenziven. Meg a Windows API-k tobbsegevel nincs kulonosebben baj,
addig a 3rdparty DLL-ek eleg valtozatos minosegu belso implementacios
koddal rendelkeznek, ami nem feltetlen felel meg a menedzselt
kornyezet kovetelmenyenek. Nagyon sok cikket olvastam arrol, hogy a
P/Invoke egy bizonyos szint felett frusztralo is tud lenni.
Szemelyesen halistennek meg nekem se volt vele nagy problemam, pedig
en nem is C#-ban, hanem VB.NET-ben fejlesztek .Net ala, ami neha eleg
trukkos megoldasokat kovetel.

Amit irtal (tanacskeres) az stimm, csak ettol meg nem lesz egyszeru
egy ilyen tervre barmi epkezlab otletet adni. Kabe minden projekt
menedzserek altali felvetesekor elhangzik (kimondva-kimondatlan), hogy
legyen olcso es gyors a fejlesztes, es minel kisebb a vegtermek.
Sajnos ebbol a harom dologbol egyszerre mindig csak kettot lehet
valasztani.

Garami Gábor
E-mail: gabor.garami at hron.me
Tel: +36 20 235 9621
MSN: hrgy at vipmail.hu
Skype: hron84


2013/2/2 János Háber <janos.haber at javaportal.hu>:
> - Nekem az jott le hogy Miklostol tanacsot kertek: "- Nem én vagyok a
> "kritikus", nem elsősorban nekem kell boldogulni vele,"
> - Mivel egyikunk se tudja hogy a "kismeretu nativ exe" mennyire fontos
> kovetelmeny igy lehet hogy megoldhato egy kisebb wrapper appal
> (qt/.net/akarmi) de lehet hogy fontos kriterium az egesz alkalmazas meretet
> tekintve.
> - Nemtudom nekem Nativ DLL hivassal nem voltak rossz tapasztalataim :),
> szempontkent peddig az alkalmazas kesobbi tovabbfejlodese szempontjabol
> irtam.
> - Mivel nemtudjuk hogy az adott fejlesztocsapat milyen nyelveket ismer (es
> FreePascal is felmerult ugye elso korben) igy ez is fuggo kerdes, de az en
> velemenyem szerint mindegyik nyelvnek megvan a maga helye plusz ekkora
> projecthez nem erzem tul nagy ugrasnak a Java -> C# atallast (legalabbis
> nekem nem volt az)
>
> Boci
>
>
>
>
> 2013/2/2 Gábor Garami <gabor.garami at hron.me>
>>
>> Felreertetted a mondatot: el tudok kepzelni ilyen alkalmazast, csak a
>> feladat felvetesebol az jott le, hogy nem akarnak tul sok eroforrast (ido,
>> penz) belefeccolni a fejlesztesbe, illetve a kesobbi karbantartasba.
>>
>> Egyebkent FYI: .Net 3.5 ma mar minden tamogatott Windows verzioban megvan,
>> vagy frissiteskent felmasz. Windows XP-re mar nem fejlesztunk nagyon.
>>
>> A webes megvalositas nekem azert jott be a kepbe, mert a leiras pont
>> raillik egy ilyenre.
>> A kismeretu nativ exe meg kimerulhet egy alapszinten osszerakott Qt-s
>> bongeszoben, ami semmit nem csinal, csak behozza a webappot. Ilyesmit kb.
>> egy-masfel nap keszre faragni, meg nagyon kodolni se kell hozza.
>>
>> Egyebkent meg nem kell bedolni a marketingnek. A P/Invoke (nativ dll
>> hivasa .Net alatt) talan nagyobb szopas, mint a JNI. Nem beszelve arrol,
>> hogy a kerdesben nem volt ilyen jellegu szempont, igy fogalmam sincs, ez
>> miert erv.
>>
>> Nekem az a koncepciom, hogy ha lehet, nem tanultatok uj nyelvet a
>> csapattarsakkal, ha a meglevo tudasbol is megoldhato a feladat. Talan
>> rosszul gondolom.
>>
>> Garami Gábor
>> gabor.garami at hron.me
>> Skype: hron84
>>
>>
>> Tel: +36 20 235 9621
>>
>> Sent from my T-Mobile G2
>> Ezt a levelet telefonról adták fel, ékezethibákat tartalmazhat.
>>
>> 2013.02.02. 23:20, "János Háber" <janos.haber at javaportal.hu> ezt írta:
>>
>>> - .NET 2.0-t azert mondtam mert a legtobb windowson van (a folott meg ki
>>> tudja)
>>> - " Ezek nelkul ma mar szerintem elkepzelhetetlen egy adatokkal dolgozo
>>> .Net alkalmazas", hasznald az erot Luke :)
>>> - A webes megvalositast azert is nem mondtam mert "kis méretű natív exe
>>> előnyben", persze ettol fuggetlenul lehet appot kore wrappelni mondjuk
>>> jettyvel, erre meg rajon barmilyen framework (mondjuk olyat nemnagyon
>>> ismerek ami ORM nelkul tudna hasonlo fukcionalitast (saccoljuk be a veget
>>> minimum 20M korulre)
>>> - Persze ha van mas nyelv tudas (D, C/C++) akkor lehet azt is hasznalni
>>> (wxWidgets, QT, GTK, FOX, es meg van egy tucat GUI lib ami hasonlot tud)
>>>
>>> De a leiras alapjan en meg mindig .NET -et ajanlanam
>>>
>>> -"Raadasul a .Net pont ugyanolyan nativ, mint a Java: semennyire."
>>>   - nem allitottam hogy nativ, aztmondtam "Nativ windows kinezetevan"
>>> (ezen felul JNI irasa nelkul kepes DLL-t kezelni ami akar elony is lehet a
>>> kesobbiekben)
>>>
>>>
>>> 2013/2/2 Gábor Garami <gabor.garami at hron.me>
>>>>
>>>> Bocsanat, hogy belepof: egy webes alkalmazas nem opcio? Ha nem, miert
>>>> nem?
>>>>
>>>> Azert erdeklodok tisztelettel, mert egy csomo olyan framework van,
>>>> ahol gyakorlatilag egy ilyen feladat implementalasa kimerul az IDE-vel
>>>> torteno kodgeneralasban, illetve a HTML formok megdizajnolasaban.
>>>> Legalabbis, a leirasodbol arra kovetkeztetek, hogy semmi bonyolultat
>>>> nem kellene tudnia az alkalmazasnak, ha felmerult az APEX, mint
>>>> implementacios platform.
>>>>
>>>> Egyebkent pedig szerintem databindinges ojjektumok (gridek pl)
>>>> elerhetoek javahoz is, ha es amennyiben te es a fejlesztocsapat
>>>> Javaban otthon erzitek magatokat, en nem feltetlen eroltetnek egy
>>>> ennyire mas kornyezetet. Habar a C# szintaxisa hasonlit a Javaera, ez
>>>> elmondhato barmely C szintaxisu nyelvre, megsincs ket egyforma
>>>> kozottuk. A C# es a Java kozott igencsak nagy elteresek vannak.
>>>>
>>>> Raadasul itt felmerult a .Net framework kerdese is. Ha engem kerdezel,
>>>> a 2.0 helyett ma mar legalabb 3.5-re kell targetalni, ha nem akarunk
>>>> nagyon sok fejlesztoi eroforrast beleolni a projektbe, ugyanis a LINQ
>>>> es a WPF viszonylag egyszeruve teszi a fejlesztest. Ezek nelkul ma mar
>>>> szerintem elkepzelhetetlen egy adatokkal dolgozo .Net alkalmazas.
>>>>
>>>> Raadasul a .Net pont ugyanolyan nativ, mint a Java: semennyire.
>>>>
>>>> Egyebkent a listadat bongeszve folyamatosan az az erzesem, hogy te egy
>>>> webes alkalmazast szeretnel fejleszteni, csak valamiert nem engedik
>>>> neked.
>>>>
>>>> Garami Gábor
>>>> E-mail: gabor.garami at hron.me
>>>> Tel: +36 20 235 9621
>>>> MSN: hrgy at vipmail.hu
>>>> Skype: hron84
>>>>
>>>>
>>>> 2013/2/2 Molnár Miklós <timortinj at freemail.hu>:
>>>> > Sziasztok,
>>>> >
>>>> >
>>>> >
>>>> > Feladat: képernyőkön keresztül kell Oracle adatbázisba adatokat
>>>> > rögzíteni
>>>> > (+valamiféle menürendszer)
>>>> >
>>>> >
>>>> >
>>>> > Milyen technológiát tartotok erre legalkalmasabbnak egyértelműen csak
>>>> > Windows alatt?
>>>> >
>>>> >
>>>> >
>>>> > Az APEX egy triviálisan létező lehetségesi opció erre (mivel Oracle
>>>> > adott és
>>>> > azon belül már ingyenes):
>>>> >
>>>> > Ami még eszembejut: Free Pascal + Lazarus kombó.
>>>> >
>>>> >
>>>> >
>>>> > Az én szempontjaim a választáshoz az alábbiak lennének:
>>>> >
>>>> > - NEM szempont tehát, hogy Linuxon és Windowson egyformán jó legyen:
>>>> > elég a
>>>> > Windows támogatása (100%-ban windows-gépeken történik a rögzítés).
>>>> >
>>>> > - Free/Open Source legyen a fejlesztő környezete (üzemeltetése)
>>>> >
>>>> > - Legkisebb "lábnyomú" (footprint), pehelysúlyú (lightweight) legyen:
>>>> > gyors
>>>> > indulású futtató-alkalmazás, kis méretű natív exe előnyben.
>>>> >
>>>> > - Minél könnyebb legyen benne fejleszteni: Java Swing és/vagy SWT-nél
>>>> > egyszerűbben.
>>>> >
>>>> > - Minél teljesebb felhasználói élményt adjon rögzítői oldalon.
>>>> >
>>>> > - Szép legyen a form. Nálam a "szép form" a régi Delphis 3rdparty
>>>> > bővítményes eszkökészlettel volt implementálható.
>>>> >
>>>> > - Billentyűzet-támogatás elegáns legyen (ne egerészni kelljen a
>>>> > rögzítőnek).
>>>> >
>>>> > - Könnyű legyen módosítani a formokat, bővíteni
>>>> > formokkal/alkalmazásokkal
>>>> >
>>>> > - Könnyű legyen üzemeltetni. Nálam a könnyű egy régi exe lecserélése
>>>> > egy
>>>> > újra például ;) És nem alkalmazás-szerver leállítása, újraindítása,
>>>> > hibák
>>>> > kezelése stb.
>>>> >
>>>> > - 64-bites natív támogatás (esetleg).
>>>> >
>>>> > - A fejlesztő környezet minél kevésbé legyen "egzotikus", abbahagyott
>>>> > fejlesztésű, kevéssé dokumentált stb (esetleg).
>>>> >
>>>> > - Több db-platform támogatása (esetleg). Eddig 100%-ban Oracle-ben
>>>> > volt/van
>>>> > minden. De a kertek alatt most lopódzik be az MSSQL Server. Emiatt egy
>>>> > APEX
>>>> > nem feltétlen előny.
>>>> >
>>>> >
>>>> >
>>>> > Na és egyéb szempont technológia-választáshoz?
>>>> >
>>>> >
>>>> >
>>>> > Köszönettel:
>>>> >
>>>> > MM
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Javalist mailing list
>>>> > Javalist at lists.javaforum.hu
>>>> > http://lists.javaforum.hu/mailman/listinfo/javalist
>>>> >
>>>> _______________________________________________
>>>> Javalist mailing list
>>>> Javalist at lists.javaforum.hu
>>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>
>>>
>>>
>>> _______________________________________________
>>> Javalist mailing list
>>> Javalist at lists.javaforum.hu
>>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>>
>>
>> _______________________________________________
>> Javalist mailing list
>> Javalist at lists.javaforum.hu
>> http://lists.javaforum.hu/mailman/listinfo/javalist
>>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>

További információk a(z) Javalist levelezőlistáról