Model/ORM v Angularu rubrika: Programování: JavaScript
Ahoj,
chtel jsem se zeptat jakym zpusobem resite "modelovani" v Angularu. Prosel jsem snad desitku modulu, ktere popisuji MODELy/ORM, ale zadny neni otimalni. Nejvic propagovany RestAngular mi nevyhovuje a sam autor rika, ze by to dnes uz resil jinak. Nedavno jsem narazil na jednoho kluka nekde z Montevidea, ktery zrovna dopsal cistounky a elegantni kus kodu, ktery resi 90% veskerych pozadavku, ale chce to jeste poradne otestovat a dodelat nejake ficury. Tim ze je to dobre navrzene podarilo se mu cele to smrsknou na nejaky 250 radek a dost mozna by se na tom dal postavit modul, ktery by se o MODEL v Angularu staral od zacatku (formular prostrednictvim Formly), az do konce (REST rozhrani) a to vcetne relaci 1:1 i 1:M. Chci nejen vycistit controllery, ale zaroven se neopakovat, ani u psani servis, protoze je to porad dokola a porad dokola tam clovek (zbytecne) seka ty same chyby.
V podstate mi jde o to aby architekt na jednom miste definoval model (jako servisu)
app.factory("House", ["$modelScaffold", function ($modelScaffold) { return $modelScaffold.newModel({ name: "House", fields: { address: "", color: "", doors: 0, windows: 0, owner: $modelScaffold.belongsTo(Person) }, methods: { metodaA: function () { ............... }, metodaB: function () { ................. } } }) })
a uz samotnym pouzitim v controlleru by slo vyhledavat, ukladat a takove ty veci, ktere bezne delame 100x jinak a pokazde stejne. Ve view by se mely dat primo adresovat relacne svazane hodnoty (dum patrici tomuto cloveku, vsichni lide co bysli v tomto dome) a developer by resil uz jenom speciality, ktere jdou mimo tech parretovskych 80%. Moje predstava je takova, ze se to na serverside postavim proti nejakemu https://github.com/baugarten/node-restful a znova 80% funkcionality pobezi bez nejakych vetsich zasahu a hlavne bez chyb.
Je to neco na co byste jako programatori slyseli? Jako kazdy mam prace na mesice dopradu a premyslim, jestli se do toho mam nejak vic angazovat. Pokud nekdo mate nejakou overenou vychytanou sestavu krabicek, ktere dokazou neco podobneho, rad se necham presvedcit a budu dal linej ;)
Já jsem si malinko upravil angular-resource o pár základních hooků a na těch jsem pak "zvenku" postavil podporu pro jednoduchý schema.
{ id: {readOnly: true}, active: {readOnly: true}, closed: {readOnly: true}, locked: {readOnly: true}, createdBy: {type: 'User', readOnly: true}, updatedBy: {type: 'User', readOnly: true}, createdAt: {type: Date, readOnly: true}, updatedAt: {type: Date, readOnly: true} }
Takže pokud dotaz na API vrátí třeba to createdBy, rovnou ho mám jako instanci resource User, createdAt jako instanci Date, read-only věci se na API neposílaj apod. Přijde mi to jako takovej kompromis. Model na klientu většinou nebýva 1:1 modelu na serveru, nejde jen o CRUD operace (pokud upravíš jeden resource a v něm dalších 5, asi nechceš, aby se poslalo 6 requestů pro každej jednotlivej, ale API na to bude mít nějaký volání), každá API to řeší trochu jinak. Některý API volání třeba nevracej celý objekty, ale jen některý fieldy a tak. To by pro implementaci nějakýho spolehlivýho UnitOfWork (resp. aby byl každej objekt stejnýho typu se stejnym ID v aplikaci jen jeden) bylo nejspíš trochu problematičtější.
Nevim, jestli existuje nějaký obecný řešení, pokud jo, taky by mě to zajímalo.
Pro zobrazení všech 2 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem: