[Javalist] Business logic scope Session beanben

[András Csányi]

2017-06-13 12:56 GMT+02:00 Gábor Auth <auth.gabor at gmail.com>:
> Hi,
>
> On Tue, Jun 13, 2017 at 12:45 PM András Csányi <sayusi.ando at gmail.com>
> wrote:
>>
>> A probléma ott van, hogy nem látom ebből a logikából mit tolhatok bele
>> egy session beanbe és mit nem. Gyanítom, hogy mindent bele lehet
>> passzírozni, de nem feltétlenül okos dolog. Nekem a fejemben a session
>> bean inkább egy repository, ami felelős az adatbázissal való
>> csevegésre, mint csinálni sokminden mást. A példákból is inkább ezt
>> látom, mint azt, hogy meppelgetnénk ide-oda.
>
>
> Nem, abban lehet mindenféle üzleti logika, mindenféle aszinkron hívás,
> teljes tranzakciókezelés, minden. Honnan jött az az ötlet, hogy csak egy
> mapper?

Szóval, akkor azt mondod, hogy egy Resource osztályba - ami egy REST endpoint -,
berakom a session beant (DI intézi ezt) és maga a session bean kap
egy-egy példányt a DI-től a REST kliensekből és mepperből, meg éppen
abból, ami kell? Akkor gyakorlatilag, amit én a fenti példámban
mondtam, hogy application ami felelős, hogy az üzleti logika lépései a
megfelelő sorrendben legyenek végrehajtva az maga a session bean.

A REST klienseket, a meppert meg mindent, ami egy-egy pici része az
üzelti logikának szeretném egy-egy librarybe kirakni, hogy tesztelhető
legyen úgy saját magában is.

Az egész gondolatmenetem és talán a butuska kérdéseim mögötti
motiváció az maga a tesztelhetőség és annak szintjei. Én abban hiszek,
hogy minden egyes pici részt külön-külön kell kezelni, tárolni egy-egy
jarban és unit tesztekkel jó alaposan körbebástyázni, hogy bármikor
fel tudjuk mérni, hogy az elvárt minőség benne van-e. Ezt követően
jönnek az integrációs tesztek, amellyel szintén a minőséget nézzük, de
annak már egy másik szintjét. És így tovább.

Személy szerint azért szeretnék ilyen teszt struktúrát építeni, hogy
már maguk az elhasaló tesztek is bírjanak információval, hogy hol van
a hiba. Azzal, hogy van egy kisebb-nagyobb integrációs tesztem és az
hasal, abból még nem feltétlenül tudom, hogy az éppen abban a tesztben
résztvevő egységek közül éppen mi nem hozza az elvárt minőséget.

.Net világban tudok ilyet építeni és boldog is vagyok tőle. Most
java/JEE van terítéken és maga az EJB ottléte, funkciója nem tiszta és
nem feltétlenül tudom hova tenni a jelenlegi világomban. .Net világban
van Entity Framework, mint ORM, vannak az Entity osztályok, maga a
WebApi, a DI és ennyi. Minden más egy-egy library, amiben csinálod,
amit csinálni szeretnél és olyan, mint EJB funkcionalitás nincsen,
vagy nem tudok róla.

>> Ellenben ezt lehet úgy is csinálni, hogy minden fenti lépést egy
>> session bean fog össze. Ennek az az előnye, hogy egyszerűbb az
>> alkalmazás. Nincsen annyi jar és valószínűleg nem lesz benne nested
>> injection, míg az előző verzióban (application-ben van az üzleti
>> logika) van.
>
>
> Nem csak lehet, hanem kell is.
>
>> Mindkét esetben a tesztelhetőség még egy kérdés. Nincsen tapasztalatom
>> java cuccok tesztelésében, így ez még itt marad nekem, mint átnézendő
>> terület. De az biztos, hogy az itt lévő lehetőségek fogják
>> meghatározni, hogy mit fogok csinálni.
>
>
> Arquillian jól használható ilyesmire. Betolod az EJB-t, mockolod a hívásait
> és teszteled.

Köszönöm, meg fogom nézni!

András