ja uz zacinam tusit ducha kitovej architektury :-) to bude tymi prikladmi!
entity, ktore zmene atributov rovno updatuju databazu. takze ten setter-update vola nejaku metodu, tak rovno v nej sa vykonaju sql dopyty. prakticky activerecord styl (ma $automobil findbyid()?).
$automobil->setZnacka(new Znacka('Audi', 'A8'));
predpokladam, ze setZnacka() vola nejaky externy objekt, ktory ma metody s realnou pracou s databazou (teda nejaky orm)
----------
v jave je to pretocene, tam je entita len kontajner na data. neimplementuje ziadne specialne rozhranie, necakaju sa od automobilu ziadne metody typu update() alebo findById(), to riesi externa trieda
takze v jave je to typicky
automobil.setZnacka(new Znacka('Audi', 'A8'));
automobilRepository.saveOrUpdate(automobil)
ano, je to anemicky styl a ano, fowler na to strasne nadava, ale
1. v jave je to cele o datach, ktore tecu cez vrstvy, ale realne oni na webe tecu aj tak: v takom angulari tecu data z widgetov do controllerov cez jsony do mvc controllera na serveri, ktory to zvaliduje, posunie do servicu, ktory to spracuje, posunie do perzistencie a ta posunie do databazy.
2. je to dominantny styl, ktory funguje.
3. technicke dovody nepustia (je tazke urobit dependency injection ORM do entity a ak to aj spravite, je tazke potom ten ORM mockovat v unit testoch a teda predpokladam, ze unit testy kit pise)
4. kyvadlo ide od objektovo orientovanych veci naspat k mentalite "tu je procedura / webservice / rest api" a "tu su spravy, co medzi nimi tecu". ... pretoze skalovanie nepusti