Java <-> C#
2009-08-17T22:13:59+02:00
2009-08-24T13:31:30+02:00
2022-07-25T11:41:36+02:00
  • Kötelező a project group managerekenek ezt olvasni és válasznolni. Az MSDN fórumot is kötelező jelleggel kell járnia a csapatoknak, oda is mehetnek a javaslatok - bár a Connect ennek a hivatalos helye.
    Mutasd a teljes hozzászólást!
  • Köszönöm, most már csak meg kell fogalmaznom kellőképp olvasható angolsággal a dolgot és már küldöm is. Az mondjuk nem tudom mennyire utópia hogy meg is csinálják...
    Mutasd a teljes hozzászólást!
  • Egyébként annak nagyon tudnék örülni ha a MS csinálna valami olyan helyet ahol lehet pár fejlesztési kérést leírni a VS-sel kapcsolatban.


    Connect

    Tényleg működik. Az én javaslataimra eddig mind válaszoltak.
    Mutasd a teljes hozzászólást!
  • Én mindenesetre megvárom. Azt amire nekem szükségem van az Express is tudja, kivéve hogy a verziókövetés egy kicsit egyszerűbb lenne a naggyal. Viszont én úgy vagyok ezzel hogy egyrészt kivárom a 2k10-et, másrészt a 2k8-ban azért vannak olyan idegesítő bugok a winforms designer házatáján (is) hogy ezért elvből nem adok pénzt. Azt persze csak remélni tudom hogy a 2k10-ben már nem lesznek, de 2010-et már azért venni fogok.

    Egyébként annak nagyon tudnék örülni ha a MS csinálna valami olyan helyet ahol lehet pár fejlesztési kérést leírni a VS-sel kapcsolatban. Pl. nagyon tud idegesíteni hogy a property editor állandóan "elmászik". Azaz ha áll az ember mondjuk a databindingen, akkor ha átmegy egy másik vezérlőre akkor a property editor aktuális mezője elmászik a fenébe ha nincs ugyanolyan bindelhető érték, és keresgetheted ki a databindinget.

    Azt sem értem hogy a leglényegesebb tulajdonságoknak (text, alignment, databinding) miért nem lehet egy külön toolbart csinálni mint ami a jobb egyéb designerekben van. Egy form szerkesztésekor 10-ből 9x ezeket piszkálja az ember. Szóval van pár hajhullatós dolog a VS-ben...
    Mutasd a teljes hozzászólást!
  • Szerver oldalon 99.9%-ban PHP/MySQL van. Legalábbis ha webről van szó. Innentől kezdve a javának pont úgy nincs esélye labdába rúgni mint az ASP.NET-nek. És persze vannak a nagy rendszerek (bankok), de az meg nagyon nem az én területem, így nagyjából tökmind1 mi van ott. És szvsz ez kb. az erre látogatók 99.9%-ára igaz.
    Mutasd a teljes hozzászólást!
  • nem winform
    2010-ben lehet h néhány felületet WPF-el csináltak, de attól még nem az egész VS .NET

    próbáld megnyitni a devenv.exe-t ILDASM-ban vagy Reflector-ban. Máris látszik h nem .NET-ben írták.
    Mutasd a teljes hozzászólást!
  • Amúgy meg mivel a userek 95%-a windowson van, úgy igazából tökmind1 hogy mi van a többi platformon.


    Desktopon igen, de szerver oldalon picit mas a helyzet...
    Mutasd a teljes hozzászólást!
  • Mit gondoltok, érdemes most akciósan (upgrade árban van) VS2008-at venni, vagy érdemesebb megvárni a VS2010-et? Ez utóbbi mikor jön ki? Szokott lenni bevezető akció?
    Mutasd a teljes hozzászólást!
  • Ennek ellenére szorgos emberek megcsinálták a gcj/classpath kombót. Iszonyatos mennyiségű meló volt benne, és elég sok mindent sikerült is implementálni. Kb. a mono készültségi foka.

    Amúgy meg mivel a userek 95%-a windowson van, úgy igazából tökmind1 hogy mi van a többi platformon. A win32 is csak windowson megy igazán, a delphi is.
    Mutasd a teljes hozzászólást!
  • "Úgy hogy kb. az az ami a mono."

    Csak java eseten nincs akkora szukseg ezekre, leven, hogy letezik hivatalos kiadas egy csomo platformra...
    Mutasd a teljes hozzászólást!
  • Úgy hogy kb. az az ami a mono. Azaz a java openszorsz reimplementációja a dokumentáció alapján. Ezek szépek és jók, de azt azért nem biztos hogy el lehet várni tőlük hogy a VS2k8 vagy a netbeans elfutkározzon rajtuk.
    Mutasd a teljes hozzászólást!
  • natív C++ -ban írták asszem. De biztos nem .NET-ben.


    Hát a VS2010 wpf-es :)
    A 2008 meg aszem winform :)
    Mutasd a teljes hozzászólást!
  • Mert a netbeans tudott futni a gcj+classpath pároson anno...


    Hogy jon ide a gcj+classpath..?
    Mutasd a teljes hozzászólást!
  • Mivel az MS-nél sosem volt cél a crossplatform működés, ezért ha valamit is megírnak c#-ban, akkor az is tele lesz p/invoke (natív) hívásokkal.
    Mutasd a teljes hozzászólást!
  • natív C++ -ban írták asszem. De biztos nem .NET-ben.
    Mutasd a teljes hozzászólást!
  • Mert a netbeans tudott futni a gcj+classpath pároson anno... Az eclipse-nek is csak egy része, de az is csak azért mert nem swingre hanem swt-re épült. Az openjdk persze más tészta, de az az eredeti sun-os java kódra épül. Ahogy amúgy a többi használható jdk is anno, Pl. az IBM-é és a Borlandé amíg még volt nekik (most nem tudom van-e). A mono winforms interfésze pedig egy ... Hála egyébként a community-nak akik kb. 2 éven keresztül pingpongoztak a wine projecttel a szálkezelés kapcsán, míg végül rájöttek hogy jobban járnak egy saját cairo tetejére ültetett implementációval. Ami meg is lett, de azóta sincs még a databinding, sőt a datagridview sem normálisan leimplementálva, és nem hogy a vs2k8, de még a sharpdevelop sem fut rajta.
    Mutasd a teljes hozzászólást!
  • Üdv

    A Visual Studio-kat C#/.Net-ben írják? Csak azért érdekelne, mert itt a kommentek szerint desktop alkalmazást nagyon könnyen lehet írni .Net-ben, könnyebben mint Javaban. Viszont NetBeans és Eclipse-t is Javaban írták, így elérhető számos platformon. Szóval a .Net-es VS esetleg tudna futni Mono-n is.
    Mutasd a teljes hozzászólást!
  • Igazából nagy vonalakban minden procedurális nyelv egyforma. Persze azért vannak különbségek, Pl. van-e OOP és sok más finomság, a skála egyik végén számomra az assembly van, a másikon a C#. Igazából azonban nem a nyelv hanem a framework elsajátítása a művészet. És ezért szeretem a .NET-et, szép nagy ugyan, de aztán azon belül ott van minden és nagy vonalakban hasonló filozófia alapján megtervezve. Nem úgy mint az olyan rendszerek esetén ahol maga az alap osztálykönyvtár nyúlfarknyi, viszont mindenki megírja a saját frameworkjét aminek az a vége hogy van 500 különféle filozófiák mentén összerakott lib amiket aztán lehet külön megtanulni, a különböző verziókat összehangolni, stb. Azaz ez ugyan nehezebben tanulható, de utána jobban boldogulsz, míg a kisebb rendszerek ugyan könnyen tanulhatóak, de a szívás csak utána jön.
    Mutasd a teljes hozzászólást!
  • Az nem profi szint. A C style nyelvek szintaxisa eléggé hasonló, nem nagyon kell külön-külön tanulgatni őket.
    Mutasd a teljes hozzászólást!
  • Pár hét alatt többet nem tudok elképzelni, akár mekkora géniusz is valaki.
    Mutasd a teljes hozzászólást!
  • De van, mindjárt kettő is. Van linq to sql és van entity framework. Az előző egy elég egyszerű kis felület a ms-sql fölé, de a célnak általában így is megfelel. A gyenge pontja csak az hogy csak ms-sql fölé használható (illetve van egy openszorszos implementáció ami elvben máshoz is, de azt nem próbáltam, ahogy a projectet nézem nem törik össze magukat a fejlesztők, ugyanakkor hosszú távon a mono-ba is be akarják emelni). A MS ennek a fejlesztését tényleg úgy tűnik jegelte. A "nagy" ORM az entity framework, ez tud többféle adatbázisszervert is (bár ezt is csak ms-sql-lel próbáltam), és ez viszont fejlődik is, a 3.5/VS2k8 még elég gáz volt, de a 3.5/SP1 / VS 2k8 SP1 már használhatóbbnak tűnik. De én ezeket még csak nyúlfarknyi projektekben használtam.
    Mutasd a teljes hozzászólást!
  • A profi szint, nem a szintaxis. Tudod: ismerem a lépéseket, de Kasparov lenyomna
    Mutasd a teljes hozzászólást!
  • linqtosql van, de annak a továbbfejlesztését, egyelőre befagyasztották pár évig.
    Viszont elég jól használható.
    Mutasd a teljes hozzászólást!
  • Még nem jutottam el eddig a .net-ben: a .NET 3.5 és VS2008 alatt nincs gyári (beépített) ORM megoldás?
    Mutasd a teljes hozzászólást!
  • "sztem sokkal tobbet keres az aki verprofi 1 nyelven, mint az aki kozephalado 10ben."
    Ezt már az ObjectiveC-s kommentnél se értettem. Szóval profi szinten egy szintaxist tudni az mire elég?
    Mutasd a teljes hozzászólást!
  • Őszintén szólva nekem nem nagyon sűrűn jött eddig olyan elő hogy ilyesmire szükségem lett volna. A Linq-t viszont naponta használom. És tényleg nagyon jó.
    Mutasd a teljes hozzászólást!
  • Dependency injection nélkül tényleg nehéz, ha egyszer már ráállt az ember agya. Nekem annak idején eltartott egy darabig, mire leesett, hogy mire is jó ez az egész. Azóta viszont boldog vagyok, és fényesen csillog a szőröm

    Gyári megoldások tényleg nincsenek, viszont szerencsére a Java/Ruby irányból szivárog át az okosság .Net-re is.

    Apropó, ha jól emlékszem volt róla szó, hogy a .Net4-ben lesz AOP támogatás. Ki tud róla, lesz ebből valami, vagy marad álom?
    Mutasd a teljes hozzászólást!
  • Plusz ilyen erővel lehetne nyelvi szintű xml/xpath támogatás is


    Az is van.
    Linq to XML a neve.

    A Linq to SQL az csak egy dolog.
    Van Linq to Objects amiben a memóriában lévő adatokat lehet manipulálni ugyanúgy mint sql-t vagy xml-t.
    És bármihez lehet írni linq providert. még amazon.com-hoz is van.

    lista
    én nem tudom mi az az NHibernate, de van ahhoz is :)
    Mutasd a teljes hozzászólást!
  • A springnek elég jó dokumentációja van, ami megtalálható a saját site-ján:
    The Spring.NET Framework

    Csak annyit tudok mondani, hogy dependency injection, vagy AOP nélkül én már nem tudok élni, és tudomásom szerint a .NET alapkönyvtáraiban sincsennek ilyen szolgáltatások.

    Mutasd a teljes hozzászólást!
  • sztem nem az a fontos melyik nyelvet ismered, hanem az, h mennyire.

    sztem sokkal tobbet keres az aki verprofi 1 nyelven, mint az aki kozephalado 10ben.
    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