[Javalist] Form & DB

2013. Feb. 3., V, 08:53:52 CET

Engedd meg, hogy csak ketto dologra reagaljak, egyreszt mert koran
van, masreszt pedig mert nincs szukseg tobbre:

> - Ráadásul itt elvesznek a .NET (express) előnyei, lehet keresni IDE-t,
> FormEditort, DataBindingot (esetleg), mindent összelőni etc.
> - Itt sem látok jelentősebb előnyt más létező megoldásokhoz képest, a
> specialitásokat figyelembevéve.
> - Bár az említett QML szimpatikusan hangzik.

A Qt-nek van sajat IDE-je, QtCreator a neve, benne beepitett
FormEditorral. Databindig tekinteteben pedig mondtam, hogy ra kellene
nezni az API doksira, mert szerintem erre szinten van beepitett
megoldasm csak az en C++ tudasom annyira korlatozott, hogy nem engedte
meg, hogy a Qt-vel a kotelezo helloworld jellegu programoknal
melyebben foglalkozzak.

Ezen felul free / opensource, folyamatosan fejlesztett, es maga a
keletkezo exe nem lesz tul nagy. Valamint valamennyire a windowsos
kliensprogramok iparagaban is kezd szabvannya valni, az EA peldaul az
Origin store klienst, ami jelenleg csak es kizarolagosan Windowsra
erheto el, Qt-ben fejleszti. Ezen felul a Qt forrasok megfeleloen
hordozhatoak is platformok kozott, ha a kesobbiekben ez igenykent
felmerul.

> - Azonnal három rétegű lesz az architektúra (plusz költség), miközben
tökéletesen elégnek látszik a kliens-szerver. Egyébként erős Win7-es
kliens-gépek vannak végfelhasználói oldalon.

Nem tudom, pontosan itt mit ertesz harom reteg alatt. Ha az alkalmazas
eleg egyszeru, szerintem nem kell a dolgokat tulbonyolitani: fogsz egy
szimpla appszervert, felcsapod egy szerverre, es valami frameworkben
leimplementalod az egesz cuccot. Ha peldaul a csapatban a .Net egy
alapveto tudas (leveled alapjan ilyen erzetek keltek bennem
szarnyrra), akkor ASP.NET-ben pl. egeszen konnyu ilyet csinalni, mert
van beepitett databinding a formokhoz, szerveroldalon meg csak annyi a
feladatod, hogy nyomkodod be a cuccokat a db-be, de nem lennek
meglepodve, ha mar erre is lenne valami wrapper, es a feladatod HTML
formok dizajnolasaban meg a framework felizgatasaban fulladna ki.

Raadasul ASP.NET futtatasara kepes IIS ma mar minden tisztessegesebb
Windowsban van, egy Windows 7-ben is.

De egyebkent Java oldalon sem gondolkodtam egy klasszikus EE
alkalmazasban. Az ebben valo implementaciohoz is letezik egy csomo
framework, aminel a dolgod megint csak kifullad a HTML dizajnkodasban.

Illetve Java oldalon meg felmerulhet a JPA + SWT kerdese is, vagy
valamilyen RCP platform (NetBeans RCP, Eclipse RCP) felhasznalasa a
projekthez. A nativ exe mindenesetre pici es gyors lesz... :-)

Szoval, ha az olcsosag cel, a lehetosegek tarhaza egeszen bo.

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

2013/2/3 Molnár Miklós <timortinj at freemail.hu>:
> Hali,
>
> Igazándiból csak annyi volt a célom, hogy a lehetőségek kerüljenek elő a
> threadben, előnyökkel-hátrányokkal.
>
> Az eddigi lista:
> - APEX (legnagyobb előnye, hogy már házon belül van, voltak rá
> szárnypróbálhgatások, nagy ellenállás nincs az irányában)
> - FreePascal (én igazándiból csak egy hátrányát látom: nem mainstraim
> ajánlás Java illetve C#-al szemben)
> - .NET (express-es) és C# (az a kérdés, hogy van-e könnyebb,
> pehelysúlyubb,célnak jobban megfelelő)
> - Web/J2EE-alkalmazás (Ez azért kilőtt, mert intranetes környezetben
> túllövés, szvsz)
>
> Kérdések:
> Q:...egy webes alkalmazas nem opcio? Ha nem, miert nem?
> A:
> - Ahogy írtam is, intranetes környezetben szerintem erős túllövés. Persze
> tudom, hogy a mainstream ajánlja, és Magyarországon is vannak rá
> tapasztalatok.
> - Azonnal három rétegű lesz az architektúra (plusz költség), miközben
> tökéletesen elégnek látszik a kliens-szerver. Egyébként erős Win7-es
> kliens-gépek vannak végfelhasználói oldalon.
> - Javánál szerintem nincs is nehezebb cucc (nyelv+API)
> - Windows-specifikus felhasználói élmény (vizuális elemek,
> billentyűzethasználat könnyedsége, stb) is a leginkább fékezett habzású
> - Én azt látom, hogy más egyszerűbb és olcsóbb, én egy előnyét sem látom
> (leszámítva, hogy mainstream), csak hátrányát
> - Az APEX csak kétrétegű (adatbázis-szerverben van): ennek minden előnyével
> és hátrányával
> - Az APEX legfelső triviliatás-szinten azonnal adja magát. Kérdés, hogy
> mennyire kell mélyebbre menni customizálásban: mert akkor már más megoldás
> is könnyebben szóbajön.
> - Nincs jellemző Java-kompetencia (sem) a cégben. De ez persze nem kizáró
> indok. :o)
> - Egyetértek Jánossal: Java/C# különbözőségek áthidalhatók lennének amúgy.
> - Ez sem natív: miközben speciális a feladat és környezet, amiben
> indokolható a dolog előnye, szvsz.
>
> Q: ...van C++ tudas a csapatban, akkor az en ajanlatom a Qt
> A:
> - Nekem semmi bajom se a C++-szak, se a QT-vel.
> - De szerintem ez megint nagyon nehéz ujdonságnak (nincs erre sem érdemi
> kompetencia)
> - Ráadásul itt elvesznek a .NET (express) előnyei, lehet keresni IDE-t,
> FormEditort, DataBindingot (esetleg), mindent összelőni etc.
> - Itt sem látok jelentősebb előnyt más létező megoldásokhoz képest, a
> specialitásokat figyelembevéve.
> - Bár az említett QML szimpatikusan hangzik.
>
> Q: Egyebkent FYI: .Net 3.5 ma mar minden tamogatott Windows verzioban
> megvan, vagy frissiteskent felmasz. Windows XP-re mar nem fejlesztunk
> nagyon.
> A: Így van. erős Win7-esek a desktopok (.NET és +JVM alapból adottak)
>
> Q: ...csak a feladat felvetesebol az jott le, hogy nem akarnak tul sok
> eroforrast (ido, penz) belefeccolni a fejlesztesbe, illetve a kesobbi
> karbantartasba.
> Q: A P/Invoke ott tud problemat okozni, ha nem csak hivogatni kell dolgokat
> benne, hanem oda-vissza adtcsere is kell, raadasul intenziven.
> A: Így van, abszolút! Mondjuk a P/Invoke-ot így még nem láttam leírva (csak
> tudtam róla), így ezzel is tanultam valamit. :o)
>
> Q: Nekem az jott le hogy Miklostol tanacsot kertek
> A: Nem. Én magam számára szeretnék csak tisztán látni, saját véleményemet
> minél korrektebben megfogalmazni tudni.
>
> Q: Kabe minden projekt menedzserek altali felvetesekor elhangzik
> (kimondva-kimondatlan), hogy legyen olcso es gyors a fejlesztes, es minel
> kisebb a vegtermek.
> A: Pontosan ez a helyzet! :o)
>
> Q: Nekem az a koncepciom, hogy ha lehet, nem tanultatok uj nyelvet a
> csapattarsakkal, ha a meglevo tudasbol is megoldhato a feladat. Talan
> rosszul gondolom.
> A:
> - Na ez egy érdekes kérdés, és számomra például nem eldöntött kérdés. :o)
> - Új eszközök (egyébként paradox módon)  jönnek-mennek a cégen belül is.
> Azokat meg kell tudni tanulni orrfelhúzás nélkül is, és ez müxik is az
> eddigi tapasztalatok szerint.
> - A Java/C++&QT kombó viszont pont azért túllövés már, mert még lebutított
> (Form-specifikus) verzióban sem triviális a befogadásuk, használatuk.
> - Nyilván egy gomb mögötti eljárást még csak-csak meg lehet módosítani nem
> Java-profiként is, mégis az az érzet van bennem, mintha valaki csak 1-2 évi
> zongoratanulás után akarna MÜPA-koncertet adni.  ;)
>
> Q: Igazabol szerintem elegge teljes kepet adtunk arrol, hogy mik a
> lehetosegek, a kompetenciakat ugy se ismerjuk, es donteni se mi fogunk :)
> A: Igen, köszönet érte!
>
> Q: APEX
> A:
> - MSSQL miatt már nem akkora truváj.
> - Én elképzelésemben egy Oracle-alkalmazáshoz egy kis APEX form-kezelés
> lehet jó, általános célú, sok felhasználós "Enterprise" form-kezeléshez már
> nem jó architektúra szerintem.
> - Adatbázis-oldalon keletkezik a terhelés, miközben az Oracle-szerverek már
> most köhögnek (+ sok a felhasználó is), miközben kvázi parlagon maradnak a
> jó kis erős Win7-es deskptopok.
> - Én nem vagyok nagy barátja a repository technológiának, amit az APEX
> használ.
> - Elkezdeni az APEX-et látványosan könnyű. A customizálásról viszont már
> könyvhegyek vannak, annyira nehéz (meglehet nehezebb, mint a .NET és C#). ;)
> - Felhasználói élmény teljessége itt is erősen kérdéses számomra.
> - Van egy előnye, ami konkrétan hátrány: tud riportálni, viszont riportoló
> eszköz van (OBIEE): nem kéne két helyen riportolni, elégnek látszik csak a
> 100% pure form-kezelés megoldása
> - Alkalmazás-frissítésben is el tudok képzelni egyszerűbbet.
> - Footprintben is van kisebb.
>
> Q: FreePascal
> A: (szerintem)
> - A Pascal a legegyszerűbb, legmagasabb szintű, tömegeknek még mindig
> (legrégebb óta) legtanítottabb nyelv az átlalános célú programozási nyelvek
> között.
> - Könnyebb benne kevésbé hibás programot írni a nagy átlagnak.
> - Elérhető felhasználói élmény vele a Delphi szintjét is meg tudja akár
> ütni.
> - Free/OpenSource, folyamatosan fejlesztett: ez szerintem nagyon fontos,
> hogy megvan itt is.
> - Data Binding alapból adott
> - Legkisebb digitális lábnyom, pici natív exe stb.
> - Az üzleti logika is tömören, minimális overheaddel reprezentálódik.
> - Case-elágazások szépen programozhatósága
>   case x of
>     'a'..'z','A'..'Z':
>       writeln('betu');
>     '0'..'9':
>       writeln('szam');
>     '[',']','(',')':
>       writeln('zarojel');
>     else
>       writeln('egyeb jel');
>   end;
> - magas szintű if például IN-használattal.
> - nincs feleslegesnek tűnő typecast.
>
> MM
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist