Administrace komentářů

Máš zapouzdřená data, která získáš getterem? Asi ne, tak nekritizuj můj messenger.

Data získaná getterem typicky zapouzdřená jsou, protože to jsou buď primitivní hodnoty, nebo něco složitějšího, a pak je to zapouzdřeno v objektu nějaké třídy (třeba ta Color apod.).

Tvůj Messenger jsem nekritizoval, jen jsem napsal, že posílá nezapouzdřená data, to ale nemusí být špatně.

Data prochází přes model, ale nevidím důvod, proč by je měl model jakkoli zpracovat/tranformovat/apod. To není jeho účelem. Má se starat pouze o správu externích datových zdrojů a to dělá.

V MVC je model jádro aplikace, obsahuje veškerou aplikační logiku a zpracovávat data je jeho účelem.

Problém je v tom, že zpravidla nechci nebo ani nesmím modifikovat strukturu databáze, protože je na ni napojena další aplikace, kterou bych takovým činem mohl nabořit.

Ok, tak to potom jo, ale já jsem tímhle omezen nebyl. Nicméně ten framework umožňuje uzamčení schématu, což v produkčním prostředí je stejně potřeba udělat, protože jinak by šel výkon do kytek. Takže do schméatu nezasahuje, pokud to nedovolíš.

Proč bych se měl babrat s aplikační logikou v PHP, když mi to udělá databáze jedním dotazem a ještě se přitom sama postará o kolize?

Protože v SQL máš jen velmi omezené možnosti aplikační logiky. V některých případech to může stačit (to, co popisuješ, vypadá jako dosti tenká vrstva nad DB). V mém případě jsem potřeboval s daty dělat různý věci, vč. třeba grafových operací, SQL by mi nestačilo ani náhodou... Jinak o schopnosti databází (rychlost hledání, detekce kolizí, apod.) pochopitelně nepřijdu ani s ORM, to by jinak nemělo smysl vůbec db používat

To jsme na tom stejně s ORM i bez něj. Navíc ti tam chybí ta databáze, asi ji máš globální. To bych nesnesl.

U tebe vidím těch řádků o dost více, zejména pokud by se měly doimplementovat ty ostatní CRUD funkce. Jestli je databáze globální záleží u tohohle ORM podle způsobu použití, v nejjednodušším případně se používá jedna globální DB a statické funkce, je ale možné používat objektové API a/nebo více DB. Ta aplikace, co jsem řešil, používá DB dvě.

Tam, kde máš dvojici getter+setter, mám plnohodnotnou třídu. Zapouzdření používám i tam, kde ty ho nemáš.

Zatím jsem v tom tvém návrhu nenašel jediný příklad zapouzdření. Například o té třídě Car výše se asi těžko dát říct, že data o autě zapouzdřuje, když s těmi daty pracuješ někde jinde úplně mimo rozhraní té třídy Car. Vždyť ta třída ani vlastně pořádně neví, jaký data drží, takže tam o nějakém zapouzdření moc nemůže být řeč...

Znovu připomínám, že to nemusí být nutně špatně, naopak je klidně možné, že to tak je lepší.