Java vs Mono
2006-08-29T14:38:29+02:00
2006-09-02T06:54:22+02:00
2022-07-19T06:08:12+02:00
  • Mondjuk őszintén szólva ez a feature nem is nagyon hiányzik, nekem legalábbis. Én a magam részéről felhasználói programokat akarok írni, nem xml kezelőt, pláne hogy a fw-ben már van egy. Ami azt illeti én is Delphis környezetből jöttem, onnan nézve a .NET kiterjeszthetősége maga a csoda.
    Ezzel együtt én egy-két hülyeségétől eltekintve a Delphivel is elvoltam valahogy.
    Mutasd a teljes hozzászólást!
  • jaa, nem, ilyen szinten nyilván kiterjeszthető a framework, különben nem keretrendszer lenne a neve (btw épp ezt a zártságot nem szerettem annak idején a Delphiben). viszont maga az fw nem moduláris - pl. nemigen tudod lecserélni benne az XML DOM kezelést úgy, hogy mondjuk a webszervizek, vagy az XML szerializáció ezentúl a sajátodat használja.

    (nem tudom, hogy Javában megoldható-e ez ilyen szinten, ami keveset foglalkoztam vele, ott működött a dolog, pont az XML parserrel)
    Mutasd a teljes hozzászólást!
  • Ez valószínűleg igaz. De szvsz a CM újraírása nem is lenne annyira nagyon jó ötlet. Viszont a dolog két irányból nyitott: egyrészt tudsz szabvány adatvezérelt komponenst fejleszteni amit bármelyik .NET-es projectbe be lehet tenni, másrészt tudsz olyan objektumokat írni amik adatforrásnak szolgálhatnak az ilyen objektumoknak. És ez az ami a lényeg.
    Ezzel szemben ha Pl. van egy Oracle ADF-re kifejlesztett vezérlő azt aligha tudod Pl. a Borland JBuilderhez kifejlesztett adatkapcsolati réteggel összekötni, de javások javítsanak ki ha tévednék...
    Mutasd a teljes hozzászólást!
  • olvassatok
    ja, nincs benne databindig :D
    Mutasd a teljes hozzászólást!
  • Nah errol beszelek. Marmint hogy ki mit valasztott. Te .net-et. En java-t. Kinek melyik filozofia van kozelebb a szivehez. De hulyeseg lenne barmelyiket is leszolni, mert X vagy Z nem ugy van benne vagy nincs megvalositva mint imadott K rendszerunkben.
    Minden nyelv valami celbol szuletett. Aztan az ido eldonti mindig, hogy bevaltja-e a remenyeket. vagy nem. A lenyeg, hogy amit hasznalunk azt hasznaljuk ki annyira, amennyire csak lehet. Eljunk meg belole s szerezzunk prog.hu-s pontokat :)
    Komolyan szolva, neha ugy erzem, hogy ez erzelmi vita pusztan. Nem hiszem (bar remelem tevedek), hogy tobben kozulunk reszt vesznek programnyelvek kidolgozasaban (illtve hozzajuk kapcsolod hivatalos API-k fejleszteseben). Emiatt sem tudunk mindenhez erdemben hozzaszolni. Ugy erzem, szakmai vita helyett hitvitava fajul ez. Inkabb csinaljuk jol, amit csinalunk.
    Mutasd a teljes hozzászólást!
  • azt dobnak amit akarnak. neha, ha ugy tartja kedvek meg exception-t is :)

    Komolyan. Nem vagtam be egy IDE-be leelenorizni :) A jovoben bevagom, csak a package is legyen mellette a szukseges classokkal ;)
    Mutasd a teljes hozzászólást!
  • Par dolog.
    1.) Nem mondtam sehol, hogy a .NET mit tud es mit nem. csak azt mondtam, mit tud a java (az en tudomasom szerint). Soha nem mondtam, hogy a .NET nem interfeszekkel dolgozik.
    Azt sem mondtam, hogy .NEt ala nem lehet sajat databindinget irni.

    2.) A szoftver eletfolyamatanak nagy reszet a teszteles teszi ki. Ez ugye attol fugg, hogy milyen tervezesi modszertant kovetunk. Aki komolyabban foglalkozik ezzel, az tudja, hogy ebbol is van jopar (s mindegyik mas problema eseten hasznos).

    3.) A databinding is lehet az uzleti logika resze. Attol fugg a te modelledben hova lett betervezve. A tervezesen mulik minden.

    Hirtelen ennyi. Elteszem magam holnapra :)
    Mutasd a teljes hozzászólást!
  • A saját CurrencyManager készítésnél meg pont előjön az a hiba, hogy a .NET-es CM bele van drótozva a kódba. Nevezetesen a BindingContext.EnsureListManager (internal) függvényben, ha IList-et, vagy IListSource-t adsz adatforrásnak, akkor egy új CurrencyManager-t fog visszaadni. Nem factoryval gyártat valakit hozzá, nincs virtuális bűvészkedés ahol a saját osztályodat megkonstruálhatod, csak egy new CurrencyManager van. Elvileg ugyan a datasource implementálhatja az ICurrencyManagerProvider interfészt, de ez épp akkora megerőszakolása lenne az OO designnek, mintha a BeginEdit-et hekkelnénk úgy meg, hogy viselkedjen "tisztességesen".

    Azaz hacsak nem akarjuk újraírni a CM-t, valamint átdesignelni az adatot tároló osztályainkat, nem tudjuk egyszerűen lecserélni a keretrendszer egy részét (ami tök független kéne hogy legyen az adatokat tároló osztályoktól, ez a databinding lényege). És sok ilyen példa van még - ha nem a beépített módszert akarjuk használni, esetleg a hibáival együtt, akkor nagyon komoly hekkelésekkel tudjuk csak azt megkerülni.


    (ezzel együtt is .net alatt fejlesztek inkább, és különben pont emiatt. hogy elég egy keretrendszer hisztijeit megértenem, együtt élni a hibáival - tökéletes kód nyilván nincs. viszont ha n alternatív megoldást lehet használni, akkor a választáshoz mindegyiket meg kell vizsgálni, mindegyik filozófiáját, kényelmetlenségeit, esetleges bugjait megismerni. ezt fölöslegesnek tartom, ha van egy használható "kincstári" megoldás. legfeljebb nem akarom lecserélni a részeit)
    Mutasd a teljes hozzászólást!
  • a .net tervezői csomó mindent nem vezettek ki publikus interfészre (rengeteg internal osztályt használ a framework), csomó membert by design nem virtuálisra deklaráltak, elég sok helyen "be van drótozva" az osztályhivatkozás.

    És ez például hol okozna gondot?

    Nem tudod megmondani neki, hogy mikor egy sort kiválasztasz (nem szerkesztésre, csak úgy), ne hívja meg a BeginEdit-et

    Nem tudom, miért várod az IEditableObject implementálásától, hogy az összes komponens, ami az IEditableObject.BeginEdit-et használja hirtelen máshogy viselkedjen, mint amúgy. Ha nem tetszik, saját CurrencyManager-t kell írni és azt használni. BindingManagerBase-ből származtatva. Helyettesítendő a BindingSource-t.

    én biztosra veszem hogy nagy szívás lenne.

    Egy meglévő, viszonylag használható rendszer azonnali használata helyett heteket tölteni azzal, hogy sajátot írsz, az mindig nagy szívás
    Mutasd a teljes hozzászólást!
  • NetBeans ala ott van a PMD, ami mindenfele hibat kepes kiszurni, legyen az nevkonvencio, vagy logikai problema. Viszont - ahogy olvastam - a topic a a ket platformrol szol, nem pedig a fejleszto eszkozokrol. :)
    Mutasd a teljes hozzászólást!
  • én különben .net párti vagyok ám...

    Azért én nem esküdnék meg rá, hogy ne tudnál saját databinding alrendszert csinálni .net alá.


    én biztosra veszem hogy nagy szívás lenne. a .net tervezői csomó mindent nem vezettek ki publikus interfészre (rengeteg internal osztályt használ a framework), csomó membert by design nem virtuálisra deklaráltak, elég sok helyen "be van drótozva" az osztályhivatkozás. a keretrendszer részeinek lecserélése nem kifejezetten támogatott .net-ben.

    IListSource, IBindingList, INotifyPropertyChange, IEditableObject, IBindableComponent


    használtam ezeket. mégis azt írom, hogy e téren nem kifejezetten működik a kiterjesztés. ki érti ezt...? :)

    (trivi ellenpélda: IEditableObject + INotifyPropertyChange-t teszel IBindingList-be, mint ahogy a nagykönyvben meg van írva, ezt megjeleníted egy DataGridView-ben. Nem tudod megmondani neki, hogy mikor egy sort kiválasztasz (nem szerkesztésre, csak úgy), ne hívja meg a BeginEdit-et)

    sajna a .net keretrendszert nem tervezték elég rugalmasra ahhoz, hogy csak úgy lecserélgessük a részeit. különben ettől lesz biztonságos és hatékony, úgyhogy az esetek 99,8%-ban annyira nem fáj a dolog. de azért lássuk, hogy más fejlesztési platformok kicsit jobban átgyúrhatók nála.
    Mutasd a teljes hozzászólást!
  • Ha van 10 eszkoz, ami nagyjabol ugyanazt oldja meg, akkor valaszthatom azt, ami az adott feladatban a legnagyobb teljesitmenyt adja le (pl sebessegre van optimalizalva vagy felhasznalok szamara).

    Most komolyan. Ha egy programban a GUI sebessége a probléma (szigorú értelemben, tehát nem a mögöttes logika molyolása fogja vissza a rendszert), ahol a GUI másik végén ülő júzer "adatbefogadási ideje" valahol a másodperc nagyságrendjében van, ott vagy az alkalmazott szoftverben van egy kapitális hiba (amit hálistennek még jóval a béta előtt ki szoktak küszöbölni), vagy a szoftverfejlesztő székén ül egy kapitális hiba.

    Megis, en ugy tapasztalom, hogy egy komolyabb projekt megvalositasanak eleg jelentos idejet (akar 60-70%-t is) a tervezes teszi ki.

    Csak úgy halkan megjegyzem, hogy ez csak akkor van így, ha a tesztelést elsunnyogták. Merthogy az szokott 80%-os részt kiszorítani magának.

    kicsit produktívabb filozófiát képvisel, a "nem baj hogy 3rd party által nem annyira bővíthető, ha minden úgyis benne van" vonalat

    Azért én nem esküdnék meg rá, hogy ne tudnál saját databinding alrendszert csinálni .net alá. Az alapkomponensek nem túl bonyolultak. A designer támogatás már jóval keményebb dió, de az is megoldható (sdk-t is adnak hozzá), de az már profi++.

    javában pedig inkább kapcsolódási pontokat, absztrakt interfészeket adnak, amire több, egymástól eltérő implementáció létezhet.

    Nézzük csak: IListSource, IBindingList, INotifyPropertyChange, IEditableObject, IBindableComponent.
    Az egyes kapcsolódási pontok .NET-ben, ami hirtelen az eszembe jutott. Van még több is.

    mivel nincs monopólium, a versengéstől, és a lehetőségek megnyitásától várható a magas minőség

    Mintha párszor már kifejtettem volna, hogy a versengés alapfeltétele, hogy a két termék ne szegmentálja a piacot egymás között. Márpedig ha egymással csöppet sem kompatibilis megoldások közül lehet választani (ahol minimum egy vastagabb wrappert kell alkotni, hogy a két megoldás együttműködjön), akkor ez a feltétel sajnos nem teljesül.

    A databinding egyszeru esetben azt jelenti valoban, hogy egy adattablat egy az egyben megjelenitesz, azonban nagyon sok esetben ez nem igaz. Sokszor kell szarmaztatott adatokat megjeleniteni stb.

    És a származtatott érték előállítása miért a DataBinding és miért nem az üzleti logika feladata?
    Mutasd a teljes hozzászólást!
  • AHA! szóval a Java fejlesztőeszközök nem dobnak warningot az elnevezési konvenciók be nem tartásánál? most elszóltad magad... :)
    Mutasd a teljes hozzászólást!
  • Elneztem. Ennyi.
    Mutasd a teljes hozzászólást!
  • Van ahol ez jól jön, ott én is kézzel csinálom. De nálam Pl. úgy 100 körül formból egy ilyen.
    Mutasd a teljes hozzászólást!
  • Az bizony öreg hiba, javában az első szónak kisbetűvel illik kezdődnie. Illik betartani a névkonvenciókat.
    Mutasd a teljes hozzászólást!
  • Azert nem szurt szemet, mert a Forum osztaly nalam pont igy van definialva Javaban :)
    Mutasd a teljes hozzászólást!
  • nem igaz, hogy neked, gyakorló Javásnak nem szúr szemet, hogy ez .NET kód. Javában gondolom .subString, és .post lett volna :)
    Mutasd a teljes hozzászólást!
  • Felteszem a kerdest: mi lenne, ha a jovoben a Databinding-el kapcsolatos allaspontok hanyagolasra kerulnenek a java-.NET -el kapcsolatos forumokban? Inkabb beszelhetunk orm-rol, WS-ekrol stb
    Mutasd a teljes hozzászólást!
  • :)
    Ha jol latom sikerult olyan kodot krealnod, ami .NET-ben es Java-ban is lefut :)

    a for helyett lehetett volna while(true) is :)

    Amugy en szivesen leszalnek databindingrol, csak zavart hogy ez az ultimate erv a java ellen.
    Mutasd a teljes hozzászólást!
  • Szerencsere eddig nem kellett atlagos ugyviteli szoftvert irnom. Viszont kellett specialis terinformatikai kutatoszoftvert terveznem es irnom. Ott nagyon-nagyon jol jott, hogy mindent a kezemben tarthattam.
    A databinding egyszeru esetben azt jelenti valoban, hogy egy adattablat egy az egyben megjelenitesz, azonban nagyon sok esetben ez nem igaz. Sokszor kell szarmaztatott adatokat megjeleniteni stb. Nekem eddig ha lett is volna ilyen Javaban, nem lett volna ra szuksegem.

    MVC. Oda akartam kilyukadni, hogy amit most ajnaroznak, hogy logikai, felulet szetvalasztas milyen fontos, az a java alapjat kepezi regota, sot sztem az OOP is valahol errol kell hogy szoljon valamilyen szinten.

    A thirdparty cuccok meg... nekem hasznosak, neked nem. Ebben mas a velemenyunk. Regebben en is szerettem, ha "egy eszkoz mindenek felett" elv ervenyesult. Viszont idovel ez nekem nem volt eleg. S hogy interface-kel barmit barhova hozzakapcsolhat az ember ? ez javaban is igy van. EJB3-nal en valasztom ki az ORM kezelot, a szervert stb. Mindegyik szabvanyos feluleten kapcsolodik.
    Mutasd a teljes hozzászólást!
  • Nézzétek, írtam egy saját fórummotort:

    if (Forum.Topic.Name.SubString ("Java") || Forum.Topic.SubString (".Net")) { for (;;) { Forum.Topic.Post ("Nem kell databinding!"); Forum.Topic.Post ("De kell databinding!"); } }
    Mutasd a teljes hozzászólást!
  • Azert nem hiszem, hogy egy databinding ilyen merteku tobbletmunkat okoz. Nalam, mivel ezt "kezzel" csinalom meg okoz tobbletmunkat, cserebe viszont szerintem tobbet nyerek, mintha 2klikkel oldanam meg.


    A databinding bizony derekas méretű többletmunkát spórol meg, legalábbis ha átlag ügyviteli szoftvert írsz. Persze ha mondjuk SQL szervert fejlesztesz akkor ez nem szempont. A másik oldalon pedig nem igazán látom hogy mit nyersz azzal hogy 5000 alkalommal beírod hogy textBox1.setText(adattabla.mezonev.getText()),
    illetve ennek fordítottját.

    Azt hiszem mondhatom, hogy a java MVC-je ennek kialakitasaban uttoro szerepet jatszott.

    Ja, meg a xerox is akik feltaláták az egert és az ikont .

    S megvalami az altalad alabecsult thirdparty cuccokrol. En szemely szerint szeretem, ha van valasztasi lehetosegem. Ha van 10 eszkoz, ami nagyjabol ugyanazt oldja meg, akkor valaszthatom azt, ami az adott feladatban a legnagyobb teljesitmenyt adja le (pl sebessegre van optimalizalva vagy felhasznalok szamara).

    Azért annyira nem különböznek a feladatok. Az adatbáziskezelés nem fúziós reaktor építés, itt már évtizedek óta kitaposott ösvények vannak. Az hogy Gipsz Jakab így oldotta meg a dolgot vagy Szurok Jenő amúgy igazából olyan egetverően nagy teljesítménykülönbséget nem okoz. Mögötte meg ugyanúgy használhatsz 1000 féle thirdparty cuccot (Pl. ORM-et, stb), vagy írhatsz is magadnak egyet ha úgy tartja úri kedved. A lényeg hogy ezek megvalósítanak egy interfészt ami biztosítja hogy ne neked kelljen egyenként odahegesztened a komponenst az adathoz. Kb. olyan ez is mint a GUI builder: össze lehet azt a GUI-t hozni a vi segítségével is, csak egy RAD toolal gyorsabb, kényelmesebb, rugalmasabb...
    Mutasd a teljes hozzászólást!
  • De van :)

    Ugy ertettem, hogy amit felhoztok ellene ervkent, hogy nem teljesiti, nem hasznalhato azok szerintem leteznek benne es hasznalhatoak.

    Amugy valoban rosszul irtam, igazad van. Majd a tovabbiakban jobban ugyelek.
    Mutasd a teljes hozzászólást!
  • A .NET-et nem ismerem (nem is velemenyezem),


    Abban viszont igen, hogy a java mint nyelv, kornyezet, plattform egyaltalan nem kevesebb a .NET-nel.


    Nincs itt egy pici ellentmondás ?
    Mutasd a teljes hozzászólást!
  • Igy van. ha kizarolag win-re fejlesztenek, akkor .NET-et tanulmanyoznam erosen. Azonban en fokent linuxra illetve plattformfuggetlenul kell kodoljak, a Java az utam. S nem elhanyagolhato, hogy megszerettem. Hiaba mernok az ember, azert vannak itt is erzesek.
    Ugyanigy Linoxt hasznalok 8 eve, mert akkor sokkal jobban hasznalhatonak tunt mint a win. Most meg mar maradok ennel mert kiszolgal amire kell. lehet win is jo lenne, de minek valtsak?

    A GUI. A sun fele gui, fokent az 1.4-es, 1.5-s eleg tre valoban. Talan a 6-ban lesz valtozas. Amugy ez sok embert zavart s ezert is alakult ki az swt.
    Amugy lehet szep dolgokat csinalni swing-el is, lasd itt.
    Mutasd a teljes hozzászólást!
  • Jahm, hát ha egy nagyobb cégnek valaki php-ben akarna fejleszteni, elég rendesen kiröhögnék.

    A nagyvállalatoknál egyelőre még a java dominánsabbnak tűnik, de szerintem csak az időtényező miatt.

    A belső webes alapú vállalatirányítási cuccoknál pldául az ASP.net robbanásszerűen tör előre, mi például szinte minden új projektet ezzel valósítunk meg, mert egyszerűen ezzel a legegyszerűbb.
    Mutasd a teljes hozzászólást!
  • igen, a filozófia a különbség.

    a .net kicsit korszerűbb, kicsit produktívabb filozófiát képvisel, a "nem baj hogy 3rd party által nem annyira bővíthető, ha minden úgyis benne van" vonalat. javában pedig inkább kapcsolódási pontokat, absztrakt interfészeket adnak, amire több, egymástól eltérő implementáció létezhet. ami elvben jobb (mivel nincs monopólium, a versengéstől, és a lehetőségek megnyitásától várható a magas minőség), gyakorlatban viszont annyira (szerintem) nem vált be.

    mindkét keretrendszerrel tökéletesen meg lehet oldani mindenfajta olyan problémát, amire ki lettek találva (mindegyik kb. ugyanarra lett kitalálva). a java előnye, hogy működik mindenféle nem MS szerverplatformon (a multiplatformság humbug, de hogy lehet Sun, IBM, Linux, stb. platformokra alatta, az komoly előny). de mivel ezekre a platformokra nem lehet .net-ben fejleszteni, ezért az alacsonyabb termelékenység valójában nem hátrány, mert nem nagyon lehet versenyeztetni őket.

    úgyhogy szerintem ha ms oprendszer alá fejlesztünk, akkor egyértelműen .net, ha nem, akkor meg egyértelműen java a célplatform (kivéve UI-ra, mert az ronda, de a XXI. században már nem muszáj az UI-t is ugyanolyan nyelven írni, mint a szerveroldali alkalmazást)
    Mutasd a teljes hozzászólást!
  • Ketsegtelen igazad van a tervezessel kapcsolatban.

    A .NET-et nem ismerem (nem is velemenyezem), egyedul csak oda akartam kilyukadni, hogy Javaban is ezek a lehetosegek rendelkezesre allnak, csak a filozofia kicsit masabb. S talan (ebben nem vagyok biztos), a Java mikor megjelent s ami meghatarozta a fejlodeset mas igenyek, filozofiak szerint lett kialakitva. S nem hinnem, hogy mindez a hatranyara valt volna.
    Ketsegtelen (s joggal elvarhato), hogy ha kijon egy uj plattform, nyelv az tanuljon az elozo rendszerek hibaibol es implementalja azok elonyeit. A .NET azt mondjak, ezt teszi. Mivel magam azt nem ismerem, ebben nem foglalnek allast.
    Abban viszont igen, hogy a java mint nyelv, kornyezet, plattform egyaltalan nem kevesebb a .NET-nel. Ahogy a linux sem az a win-nel. Mindegyik mas filozofiat kovet, amelyek nehol talalkoznak, nehol ellentmondanak egymasnak. Mindegyik mashol jo, jobb. Van ahol meg versenyhelyzet van. De ebben a szakmaban ez az egyik szepseg, szerintem :)
    Mutasd a teljes hozzászólást!
  • maradjunk annyiban, hogy az ember mostmar nem tervez a GC szintje alatt, hisz a VM maga is egy kontroll.
    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