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

• Aethelstone addikt

  #7235

  #7234 floatr

  2015-04-17 12:25:49

  Ú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

  

  Aethelstone

  addikt

  #7234 floatr

  #7234 floatr

  Amit eddig láttam, az alapján azt tudom mondani, hogy amint a projekt megéri a telepítési fázist kiderül, hogy bármilyen generált kódról is van szó, a fejlesztők csak becsapják magukat, hogy majd sokkal kevesebbet kell kódolni. Hihetetlenül észnél kell lenni, mert elég egy legyintés, hogy ez így majdnem jó, és oda minden előnye a generált cuccoknak. Ezt a legtöbben nem is látják, mert valamiért nem foglalkoznak a release utáni életciklussal. Ugyanez igaz a DTO-ra is, hogy leszámítva azt az 1%-ot, amikor tényleg kellene, csak felesleges karbantartási köröket, és kockázati tényezőt vezetnek be a projektbe. Az ember hajlamos elsiklani olyan problémák felett, amiket nem lát rögtön, mert kényelmes nem szembesülni vele.

  Hibernate-tel már odáig jutottunk, hogy az összes előnye leredukálódott a bean alapú row mappingre, és az öröklődés kezelésére. Nem 1% az, amit kézimunkával kell megoldani, de erről már a múltkor beszéltünk a lazy-eager-dto témában.

  Nálunk a legtöbb szívás a GWT-vel a frontend hibái miatt voltak. Még csak nem is a generált kód és a backend közti szakadék miatt. A frontendesek annyira sokat dolgoztak a minimális hibákon, hogy a végeredmény az lett, hogy vagy sikerült megalkudni a megrendelővel, vagy addig hegesztették böngészőnként a dolgot, hogy az összköltsége elszaladt egy bootstrap/foundation alapokra épülő jquery/sencha kliens + SOA backend mellett. Sajnos vagy sem, de eddig mindig ide lyukadtunk ki, akármi is volt a kiindulási alap.

  Hibernate-tel már odáig jutottunk, hogy az összes előnye leredukálódott a bean alapú row mappingre, és az öröklődés kezelésére.

  Kb. ennyi volt az előnye mindig is

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