Új hozzászólás Aktív témák

• floatr veterán

  #4926

  #4923 MrSealRD

  2014-02-04 09:56:26

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  floatr

  veterán

  #4923 MrSealRD

  #4923 MrSealRD

  A vékony kliens részét is mi írjuk viszont van egy másik aspektusa is a történetnek.
  2 meló indul közel azonos időben. Egyik .net a másik java alapú lesz. Az egyik fő szabály pedig az, hogy a körülményekhez képest a lehető legegyformább legyen a kettő...Ezért az "klasszikus" MVC-s megoldásokat mint a Spring MVC, és a Asp.net MVC kukába dobtuk. Magát a Spring fw-t nem csak az mvc részét. Mivel nem fogunk pl java kódból html-t generálni.

  A 3 réteg eddig vázlat szerűen így néz ki.(egyelőre)
  1. Kliens oldalvékony) HTML5,CSS3,JS-> JQuery és/vagy Ext.JS technológiák használata. Gyakorlatilag statikus html oldalak amik a dizájnt határozzák meg. JavaScriptből AJAX hívásokon keresztül megyünk a második réteg felé...
  2. Szerver oldal: .net oldalon wcf service, java oldalon valamilyen web service-ek vannak és minden komolyabb logika ide kerül...
  ORM hibernate illetve nhibernate lesz.
  3. DB oldalon pedig a .net-es történet oracle-ben végződik, a java-s még képlékeny...

  Bizonyos szempontból tök jó a dolog, viszont az, hogy heréltük a Spring egyik erős képességét, hát az annyira már nem...Na és akkor itt jön a történetbe az alkalmazásszerver kiválasztása...
  Nekem ez így kicsit sántít egyelőre, de indokolni nem nagyon tudom, mert sok az ismeretlen az egyenletben.

  Köszi a segítséget.

  Egy ideje ezen az architektúrán fejlesztek, úgyhogy csak ajánlani tudom. Ha a cél egy olyan vékony kliens, ami mobilon is életképes, akkor érdemes még fontolgatni az MVC-t, bár az újabb telefonok már az ExtJS/Sencha Touch elemekkel is jól kijönnek. Spring MVC-t nem feltétlenül kell használni egy ilyen projektben, mert sokkal több dolog van benne, mint ami kellhet. Adatkapcsolati eszközként én DWR-t használom.

  JQuery: gyakorlatilag ipari standard bár verziófüggőségi problémákkal én rengeteget szoptam. A korábban frontenddel foglalkozó fejlesztők szeretik, mert közelebb áll az ő gondolkodásmódjukhoz, de ha komplexebb dolgot kell benne megvalósítani, akkor a pluginekkel elég nagy problémákat vesz a nyakába az ember, mivel elég sovány a támogatásuk. Ha az ember nem expert, akkor csak a pluginek közti turkálás lesz belőle.

  ExtJS: én ezt használom régóta, és a legtöbbször ezt is javaslom. Jó a supportja, és elég sokrétű felhasználási lehetőségei vannak. Egyrészt a magja közelebb áll a Java-s fejlesztőkhöz, és kellően testreszabható ahhoz h saját komponenseket használj tetszőleges felületi elemekhez. Másrészt van egy elég komoly adatkezelési mechanizmusa, aminek szvsz még a dojo sem ér a nyomába. Aztán ott van a komponenskészlete, ami desktop alkalmazások építőelemeire hajaz, és ráadásul még az ie6 is támogatott.

  DWR: ha nem ismered, akkor nosza rajta. Írni is akartam egy kisebb cikket ezzel kapcsolatban, mert sokaknak teljesen ufó a dolog. A lényege annyi, hogy egy webservice-szerű szolgáltatási réteget a szerveren bekonfigurálva generál egy javascript csomagot, amiben megtalálod a szolgáltatásaid metódusait, és az adathordozó osztályokat. Magyarán JS-ből közvetlenül eléred a Java szolgáltatásaidat úgy, hogy még a bean-jeidet is létre tudod hozni a kliensnél. ExtJS-hez pár bővítmény kell, hogy az adatkapcsolat kezelhető legyen (én írtam ilyent )

  Spring MVC: a DWR nem egy szabványos rendszer, ezért gyakran előfordul, hogy a spring RESTful webservice eszköztárára van szükség. Mondjuk ez sem teljesen szabványos, mint implementáció, de ezt legalább tudod használni bármilyen servlet konténerrel, nem kell hozzá vaskos JBoss. Jackson2-vel használva egy JS library számára az egyik legkezesebb eszköz. Tudok hozzá adni olyan komponenst ExtJS-hez, amivel majdnem DWR-szerű hívások szintjére lehet felhozni a kezelhetőségét.

  Spring konténer: én enélkül el sem indulnék egy projektben elsősorban XML-alapú konfigurációval.

  Hibernate: próbáltam szabadulni tőle, de mindig ide jutottam vissza. Amikor hierarchikus adatmodelled van, nem mondom h megkerülhetetlen, de erősen ajánlott. Főként a komplexebb lekérdezéseknél jól jön a HQL és a natív SQL-binding. Spring-gel együtt használva érdemes a Spring Data/JPA oldaláról támadni, mert az mégiscsak modernebb, mint a HibernateTemplate. Kísérleteztem még QueryDSL-el is, de azt csak egyszerűbb lekérdezésekig érdemes használni -- mondjuk azokra mindenképpen érdemes.

• Karma félisten

  #4924

  #4923 MrSealRD

  2014-02-04 07:26:35

  Új Válasz

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  

  Karma

  félisten

  #4923 MrSealRD

  #4923 MrSealRD

  A vékony kliens részét is mi írjuk viszont van egy másik aspektusa is a történetnek.
  2 meló indul közel azonos időben. Egyik .net a másik java alapú lesz. Az egyik fő szabály pedig az, hogy a körülményekhez képest a lehető legegyformább legyen a kettő...Ezért az "klasszikus" MVC-s megoldásokat mint a Spring MVC, és a Asp.net MVC kukába dobtuk. Magát a Spring fw-t nem csak az mvc részét. Mivel nem fogunk pl java kódból html-t generálni.

  A 3 réteg eddig vázlat szerűen így néz ki.(egyelőre)
  1. Kliens oldalvékony) HTML5,CSS3,JS-> JQuery és/vagy Ext.JS technológiák használata. Gyakorlatilag statikus html oldalak amik a dizájnt határozzák meg. JavaScriptből AJAX hívásokon keresztül megyünk a második réteg felé...
  2. Szerver oldal: .net oldalon wcf service, java oldalon valamilyen web service-ek vannak és minden komolyabb logika ide kerül...
  ORM hibernate illetve nhibernate lesz.
  3. DB oldalon pedig a .net-es történet oracle-ben végződik, a java-s még képlékeny...

  Bizonyos szempontból tök jó a dolog, viszont az, hogy heréltük a Spring egyik erős képességét, hát az annyira már nem...Na és akkor itt jön a történetbe az alkalmazásszerver kiválasztása...
  Nekem ez így kicsit sántít egyelőre, de indokolni nem nagyon tudom, mert sok az ismeretlen az egyenletben.

  Köszi a segítséget.

  Ha viszont ennyire kiheréled a Springet, nem is muszáj egyáltalán afelé menned. Jerseyvel például szintén elég jó REST kontrollereket lehet írni.

  .NET-en meg WCF helyett használhatsz ServiceStacket vagy ASP.NET Web API-t is.

Új hozzászólás Aktív témák