Java és .NET frameworkök és technológiák
2007-05-20T21:36:17+02:00
2007-05-28T19:35:10+02:00
2022-07-26T09:26:13+02:00
  • A teljesség igyénye nélkül említsük még meg akkor:

    MS Biztalk Server mellett, a
    Commerce Servert, meg a Content Management Server-t is.
    Ezek már Enterprise leve dolgok, bár sok enterprise app e nélkül is megél :) de ha sok "píze" van a customernek, akkor hadd' szóljon!

    De alapvetően a .net alatt megélsz alk.szerver cuccok nélkül is. Ez nem java. (és nem is olyan lassú, bár tudjuk a Java is csak azé' olyan ,mert pontosan számol ;) )
    Mutasd a teljes hozzászólást!
  • Köszi mindenkinek a válaszokat, jobban képbe kerültem.
    Mutasd a teljes hozzászólást!
  • Nekem az Aqualogic-hoz a Biztalk tűnik leginkább hasonlónak. Ő az amit hasonló dolgokra lehet használni.
    Mutasd a teljes hozzászólást!

  • Mit értesz standalone kontener termék alatt.

    Pl a sharepoint szerver jó keretet adhat a .NET-es fejlesztésekhez. Ráadásul egy reporting serverrel összepárosítva elég ütőképes.


    Olyan termekre, mint pl. egy Java application server (Weblogic server) vagy service bus motor (Aqualogic).

    Mutasd a teljes hozzászólást!
  • Mit értesz standalone kontener termék alatt.

    Pl a sharepoint szerver jó keretet adhat a .NET-es fejlesztésekhez. Ráadásul egy reporting serverrel összepárosítva elég ütőképes.
    Mutasd a teljes hozzászólást!
  • Miert nincsenek kesz standalone kontener termekek?


    Hat errol a gyartokat kellene megkerdezni
    Mutasd a teljes hozzászólást!
  • El is jutottunk oda ahova akartam:

    Miert nem csinalnak .NET-re alkalmazas szervereket mint J2EE-ben? Miert nincsenek kesz standalone kontener termekek?
    Ha ilyet ad a .NET, miert nem soroltatok fel?
    Mutasd a teljes hozzászólást!
  • .NET-ben kommunikaciora WCF
    WCF-et host-olni lehet
    - IIS-bol
    - Self hosting

    az IIS nagyon jo, ha XML/SOAP (WS, WS*) megfelel

    ha nem, akkor Self hosting, ami lehet:
    - console app
    - win app
    - windows service

    a Self hosting elonyei:
    - nagyon konnyu hasznalni
    - teljes felugyelet (programbol)
    - egyszeru debug
    - minden atvitelimod tamogatott

    ami gond:
    - a hosting app-nak futnia kell
    - nagy rendelkezesre allas
    - egyszeru felugyelet (felugyeleti eszkozok hianya)
    - robosztussag (huh, de szep szo :))
    - stb
    ezek out-of-the-box nem allnak rendelkezesre, sajat implementaciot kell kesziteni
    ha valaki tud kesz rendszert w2003-ra szoljon :)

    jovo ill jelen:
    Vista es w2008 eseten rendelkezesre all a Windows Process Activation Service (WAS), ez a korabbi problemak kozul sokat megold
    pl: hasonlo process model mint az IIS, de nincs XML-hez kotve.
    Mutasd a teljes hozzászólást!
  • a backend rendszerek is egyre többször használnak valami xml-re épülő homlokzatot (sima soap webszervizt, vagy wcf-et). ahol az xml használata tényleg teljesítményproblémához vezet, ott persze nem, és az olyan rendszereket természetesen nem iis-ben hostolják, de az általános az, hogy több haszonnal jár a nyílt üzenetformátum, mint amekkora teljesítménykiesést jelent holmi XML feldolgozás.
    Mutasd a teljes hozzászólást!
  • A gondom vele az, hogy egy enterprise rendszerben nem csak web frontend szerverek vannak (hanem ilyen-olyan backend rendszerek is), es ezek egymassal nem csak web service-eken at kommunikalnak (mert az XML szerializalas/deszerializalas lassu).

    Az ilyen backend rendszerek szamara nem latom az IIS szukseget...
    Mutasd a teljes hozzászólást!
  • nem olyan randa az. az iis-t pont ilyenek miatt felkészítették arra, hogy .net enterspájz alkalmazásokat értelmesen hostoljon. pl. tűrhető benne a process recycling / watchdog funkcionalitás, az alkalmazás élettartam kontroll, a skálázhatóság, a biztonság. legtöbb feladatra ideális megoldás.

    (olyankor nem jó pl., ha wf-et használsz, kicsit összevesznek. de annak hogy ki aktiválja a feldolgozó processzt, nincs köze az alkalmazás felépítéséhez, annyira, hogy a totál architekturális buzzword soa referenciaalkalmazások is iis hostoltak)
    Mutasd a teljes hozzászólást!

  • 1. iis webalkalmazásként: sima mezei webapplication, van context (httpcontextből), a funkciókat könnyű publikálni webszervízként. iis kezeli az autentikációt, a skálázhatóságot, stb


    Ez nekem nem tunik enterprise alkalmazas kategorianak... egy szal mezei web/application server reteg? Ez tenyleg az enterspajz kategoria, a szo derogativ ertelmeben...
    Mutasd a teljes hozzászólást!
  • enterspájz alkalmazást kb. három helyen szokás hostolni .net alatt

    1. iis webalkalmazásként: sima mezei webapplication, van context (httpcontextből), a funkciókat könnyű publikálni webszervízként. iis kezeli az autentikációt, a skálázhatóságot, stb

    2. windows service-ként: ez a gyalog módszer, itt mindent nekünk kell megoldani (skálázhatóság, funkciók publikálása, bár a wcf óta szervizben is lehet webszervizt hostolni, process recycling, miegymás). viszont itt a legnagyobb a kontrollunk

    3. serviced component (com+): ez a rendkívül fúj módszer, kompatibilitási meg jobbhíján okokból van támogatva, hogy a standard dcom feature-kat (application pooling, recycling, security, tranzakciókezelés) tudjuk használni. ma már mindegyik problémára jobb a nem com+ megoldás, .net 1.1-es időkben még nem így volt
    Mutasd a teljes hozzászólást!
  • IIS alá deployolunk.EZ van minden Windowsban (szinte)
    Vagy a Visual Studio beépített "lejátszóját" használjuk.
    Mutasd a teljes hozzászólást!
  • Ami még jól jöhet a frameworkhöz:

    Enterprise Library 3.0

    Na ebben van sok jó cucc:


    Enterprise Library 3.0–April 2007 contains the following general purpose application blocks:

    Caching Application Block. Developers can use this application block to incorporate a local cache in their applications.
    Cryptography Application Block. Developers can use this application block to incorporate hashing and symmetric encryption in their applications.
    Data Access Application Block. Developers can use this application block to incorporate standard database functionality in their applications.
    Exception Handling Application Block. Developers and policy makers can use this application block to create a consistent strategy for processing exceptions that occur throughout the architectural layers of enterprise applications.
    Logging Application Block. Developers can use this application block to include standard logging functionality in their applications.
    Policy Injection Application Block. Developers can use this application block to implement interception policies that can be used to streamline the implementation of common features, such as logging, caching, exception handling, and validation, across an application.
    Security Application Block. Developers can use this application block to incorporate authorization and security caching functionality in their applications.
    Validation Application Block. Developers can use this application block to create validation rules for business objects that can be used across different layers of their applications.
    Mutasd a teljes hozzászólást!
  • Sziasztok !

    És mi a helyzet a J2EE szerver oldali dolgaival?
    Példálul mi a megfelelője a EJB-s dolgoknak?
    Vagy egy kicsit konkrétabb kérdés, hogy .NET fejlesztésnél mit használnak pl Tomcat helyett?
    Persze simán lehet, hogy rosz a kérdésem, mivel .NET-ben nem vagyok jártas.
    Gondolom ott is van valami alkalmazás-szerver ami alá kell deploy-olni.
    Mutasd a teljes hozzászólást!
  • Bár én még csak viszonylag rövid ideje, úgy egy éve .NET-ezek intenzívebben, a javát pedig csak felületesen ismerem, pár kérdésre megpróbálok válaszolni:

    ORM: Van pár megoldás, ingyenesek is mint az nhibernate meg fizetősek is. Én őszintén szólva nem ezt használom hanem a dataset/datatable megoldást, az én céljaimnak ez jobban megfelel mint egy ORM (nekem ugyanis lényeges hogy run-time tudjak mezőket adni a táblákhoz).

    xml binding eszköz: Őszintén szólva nem tudom mint tud a Jaxb, ráadásul xml-t elég ritkán kezelek közvetlenül, de a System.xml-lel viszonylag könnyű xml-t kezelni, még akkor játszottam vele amikor a .NET-et tanultam úgy egy éve.

    Amúgy mindkét témában érdemes utánanézni a .NET 3.x lehetőségeinek, LinQ, DLinQ, XLinQ címszó alatt, illetve letölteni a Visual Studió Orcas bétáját.

    Struts: Itt ASP.NET van, szépen formokon vizuálisan tudod megcsinálni a weblapodat, nyomógombokkal, gridekkel vagy akár saját vezérlőkkel, ezekhez databinding is van akár közvetlenül adatbázistáblába akár üzleti objektumba akár xml-be, illetve van keretrendszer az ajaxhoz, az ajax.asp.net címen keresd.

    Logolás: A System.Diagnostic alatt találsz egy EventLog osztályt, elég sok mindent tud.
    Mutasd a teljes hozzászólást!
  • Röviden úgy lehetne válaszolni, hogy ezt mind beépítve tudja, semmilyen külső osztálykönyvtárra, keretrendszerre, miegymásra nincs szükség. A .NET tervezésekor tanultak a Java ilyen hibáiból és minden fontos dolgot beletettek, így nem csak hogy beépítve van, de a .NET alatt írt programok, komponensek kompatibilisek is egymással, nem kel azon agyalni, hogy az adott triviális dolgot egy program melyik kiegészítő keretrendszerrel oldotta meg.

    A konkrét válasz bedig: DataBinding, XmlDataBinding, ASP.NET, System.Diagnostics

    Az objktum-relációra pedig mostanában lesz egy új, ütős eszköz, aminek a CTP-je már jó ideje kipróbálható: Linq
    Mutasd a teljes hozzászólást!
  • Üdv

    Eddig Java-ban tevékenykedtem és most .NET felé is nyitni szeretnék. Ami leginkább érdekel, hogy a Javaban megszokott technológiáknak és keretrendszereknek milyen megfelelői vannak .NET-ben.
    Felsorolok néhány Javabeli megvalósítást, és szeretném a .NET-ben, vagy mindkettőben jártas emberkéket megkérni, hogy írják le hogy ők melyeket preferálják az adott problémákhoz .NET alatt.

    Néhány (csak 1-1 Javabeli megoldást mondok, nyilván mindegyikből többféle van):

    objektum-relációs (adatbázis) binding eszköz
    Hibernate (úgy láttam .NET-re is létezik) - ....

    xml binding eszköz
    Jaxb (írták, hogy .NET-ben van ilyen beépítve System.Xml.Serialization-ben) - ....

    Keretrendszer webes alkalmazásokhoz
    Struts 2 - ....

    Logolás
    log4j (van log4net is) - ....

    Ezeken kívül még bármilyen témával kapcsolatos keretrendszereket szívesen fogadok (pl. általános hálózati keretrendszer - Apache MINA), a kérdésem nem csak a fentiekre vonatkozik.

    Természetesen google-el is előkaparhatok ilyeneket, de személyes vélemény jobban érdekel.
    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