2010-06-25

JUM XV.

A XV JUM-ról gyorsan, késve:
Csúszott is a dátum, nem is jött be a terv, de azért lett két jó előadás.

Bemelegítésnek Kovács Richárd a BTrace-ről nyomta:
Különös alternatívája ez a debug-olásnak. Java-ban lehet megírni a kódot ami végrehajtódik, ha ráfut a vezérlés a megadott metódusokra. A Java-ban megírt kódnak viszont rengeteg kötöttsége van. Nem lehet új objektumot létrehozni, ciklus sem lehet, ilyesmik. Használhatónak tűnt az a felhasználási eset, amikor a JDBC csomagban lévő osztályok bizonyos metódusaira kötöttek debug kódot és kiírták hogy milyen SQL-ek mennek az adatbázis felé. (ORM esetén hasznos.)

Marhefka István a Domain Driven Design-ről beszélt:
Sok embernek talán bullshit-nek tűnhet a DDD. Van róla könyv angolul Eric Evans-tól. Íme a DDD főbb ismérvei:

Tiszta domain modell: A domain modellnek ne legyenek technikai függőségei. Ebbe szőrmentén az a kérdéskör is beletartozik, hogy az entitásokat ellássuk-e JPA annotációkkal vagy inkább XML-be tegyük a perzisztálási információt. De semmiképpen sem jó teleszőni a business logikát mindenféle keretrendszer és kommunikáció specifikus osztályokkal, mert így taligával toljuk a projektbe a kockázatokat: hordozhatatlanság, tesztelhetetlenség, bottleneck-ek, business és licenszelési szintű problémák.

Inversion of Control: A DDD egyik eszköze. Nem esett róla szó, de arra (is) való hogy egy nemkívánt irányú függőséget megfordítsunk. (Bővebben: Robert C. Martin, Agile software Development)

Magyarítás: Egyik blogon éppen megy a bokszmeccs. Én is abba a táborba tartozom, aki nem igazán magyarítana, bár sajnos nem tudok bekommentelni, mert minden magyar blog le van tiltva itt nálunk. (Jó hely...) Annó leírtam már a véleményemet ebben a témában, ami azóta sem változott.

Dual data source: A dolog lényege, hogy nem ugyanazon az úton nyerjük ki a perzisztens adatokat, mint ahogy beletettük őket valahova. Pl. JPA-val perzisztáljuk az adatokat, de SQL-lel szedjük ki őket. Ez jóval hatékonyabb lehet bizonyos esetekben, mert meg lehet spórolni a (java) objektumokra való mappelést. Meghökkentően hangzik, de néha mi is használjuk. Sőt, ha belegondolok ez egy funkcionális megközelítés. A perzisztens tár maga egy függvény, ami egy tranzakción belül konstans értékeket ad vissza. A service metódusaink kimenete, visszatérési értéke pedig egy utasítássorozat (Command Pattern), ami beír majd a perzisztens tárba. Érthető? Nem?

NoSQL: Ami nem azt jelenti hogy NO, hanem hogy NOT ONLY. Cesjava írt róla sokat, úgyhogy nem is részletezem.

DTO: Azaz Data Transfer Object. Nagy viták célpontja hogy legyen avagy ne legyen. Mostanában olyan (RestFul) architektúrákkal találkozom hogy egyértelműen kell hogy legyen és mellesleg nem is Java objektum hanem JSON (JavaScript) vagy XML.

Nagyjából ennyi maradt meg bennem. Nyáron szünet, ősszel találkozunk!

4 megjegyzés:

Marhefka, István írta...

Azt hiszem, van egy kis keveredés a szakmában a NoSQL tekintetében. Olvastam olyat is, hogy külön van NOSQL és NoSQL is. Az egyik jelenti azt, hogy "Not Only", a másik pedig egyértelműen elutasítja az SQL-eket. (Azt már nem tudom, melyik-melyik volt :))

Kristof Jozsa írta...

az inversion of control nem a DDD egyik eszköze.

pcjuzer írta...

Kristof: kifejtenéd bővebben?

Shalini írta...

We did see E-World Tours which seemed good. The only problem is that E-World tours start from Brooklyn or Edison,NJ which is not convenient to access for us. Our base for the holiday is Pennington, NJ.

Essentially, we are looking for these tours to start from Penn Station in NYC or Hamilton, Trenton, Princeton or Hightstown (NJ). We know that the possibility of tours starting in the NJ towns is low, but still enquiring.

The bus tour should include a night's stay, and come back to NYC/NJ the next evening.

Thank you.

web design company in chennai