Dos és Don ‘ ts: Webdynpro kontextus.

számomra úgy tűnik, hogy ezek a szabályok A teljesítmény javítására irányulnak.

van néhány megjegyzésem néhány szabályról:

• követelmény nélkül (több vezérlőben történő használat) Ne hozzon létre kontextust az Összetevővezérlő szintjén, ha szükséges, hozzon létre helyi kontextusokat, például nézetekben

az összetevővezérlő a kontextus központi hubja. Ha bármikor van olyan kontextuscsomópontja, amely több nézetben van megosztva, akkor létre kell hoznia a csomópontot az összetevővezérlőben, és más nézetekre kell leképeznie.

egy adott nézetre jellemző csomópontok közvetlenül a nézetkörnyezetben hozhatók létre, de az olvashatóság és az egységesség érdekében gyakran úgy döntök, hogy az összes kontextuscsomópontot és ellátási metódust központosítom a komponensvezérlőben.

• használjon szingulett csomópontokat, ha nestings (master detail) szükséges

a szingulett csomópontok jó teljesítményt nyújtanak, mert a csomópontnak csak egy példányát tartja a memóriában, ahelyett, hogy minden (inaktív) szülőobjektumhoz több példány lenne. Azonban jobb, ha tudja, mit csinál, mert ha jön a helyzet, amikor szükség van több aktív szülő elemek (sor ismétlő, beágyazott táblák, fák, multiselection táblák…) a singleton csomópont kiírja az alkalmazást.

ha nem ismeri jól a singleton csomópontok elvét, vagy ha a teljesítmény nem jelent problémát, ne használjon singleton csomópontokat.

• ne használjon dinamikus attribútumokat (IF_WD_CONTEXT_NODE_INFO – > ADD_ATTRIBUTE)

ha használhat statikusan definiált kontextusattribútumokat, akkor használjon statikus attribútumokat. Vannak azonban olyan helyzetek, amikor dinamikusan létre kell hoznia a kontextust. Ezekben az esetekben nincs más választása, mint dinamikus attribútumok hozzáadása. Egyetértek azonban azzal, hogy amennyire csak lehetséges, kerülje a dinamikus kontextus programozást (és a dinamikus nézet programozást).

• a bind_table

kontextusszerkezetű adatok használata nem nehéz követelmény, belsőleg a kötési műveletek áthelyezésnek megfelelőt használnak, és az eredeti táblát árnyékváltozóban tartják. Bár a lépés-megfelelő állítólag rossz a teljesítmény szempontjából. (Állítólag azért mondom, mert teszteket végeztem magamon, és nem találtam szignifikáns különbséget)

• csak akkor frissítse a kontextust, ha az adatokat ténylegesen frissíteni kell

attól függ, hogy mit jelent a frissítés?

• ne hozzon létre hosszú kontextus-leképezési láncokat.

?

• használja a Kontextusváltozási napló funkciókat a felhasználói bevitel észleléséhez. Ennek különleges teljesítmény-előnyei vannak, miközben az alkalmazás felhasználója csak kis mennyiségű adatot módosít egy nézetben, miközben nagy mennyiségű vegyes adatot jelenít meg.

igaz. A kontextusváltási napló nagyon erős lehet, ha dinamikus módon használják.

de ez is nagyon fejlett. Van egy kódrészletem, amely végigvezeti az összes változást egy kontextusban, hozzárendeli az adatokat a megfelelő változóhoz az assistance osztályban (mező a struktúrában vagy mező egy sorban egy belső táblában), és dinamikusan hív egy kezelő metódust (ha van ilyen). Ezt a részletet sok magasan képzett fejlesztővel osztottam meg. A mai napig csak 2 értette meg, hogy mit tett, és képesek voltak alkalmazni a saját összetevőikre.

az Ön által említett szabályok elég érdekesek, de mint Steve említette, érdemes lehet részletezni a célt és a mögöttes ötletet.

egészségünkre!