#SPC09 : Guidance for SP application
enfin une session sur l’architecture applicative par ce cher MikeAm, pour une session choisie au hasardm je suis veinard
Objetifs :
- SP list or DB
- 1 Site or many
- No code, sandboxed or solution
Ne jamais oublier que SP reste une immense boite à outils pour les developpeurs
Service Application
- access to shared data outside of a sp site
- very specialized
- long running operation
- scale out strategy
- BAD
>>> service long et consommateur comme le search par ex
Site creation
- One or many
- one
- content site : ootb + admin manu
- big app site : layout + wp tout app
- many
- site extension : modify existing experience
- stapled, delegate, site definition
- new events help like listadd webadd
- reauire site and web feature
- site app : specific task and site like Fantastic 40, meeting wksp
- small low impact app
- cloned instance
- Specialty site
- aggregate functionnality form other site
- group content for deliver datas to other
- Fleet of site collections : my site par ex
- many cloned instances
- host header for better security
points importants
- spwebs : center of univers
- different site are differents
- web metadata always get prefetched
- site collections
- no cross site coll
- au mieux 1 site col = 1 DB
Attention aux updates
- feature versionning can help
- feature quey api permet de découvrir leur utilisation
- uninstallation could be tricky
Choix du tout code dnqs un receiver que le déclaratif XML
- easy upgrades and to the point
- cost provisionning perf
SP DATA
- lookup multiple
- joins
- delete restrict
- cascade delete
- store level enforcement
- unique fields
- compound indices
- in clause pour des reverses lookup
- formula based validation
mais ce qui reste bloquant
- pas d’aggregation queries
- pas de disctinct
- pas de full cross list views
- pas de transactionnal updates
Limits de perf
- 5000 est la limite par def
- 50000 unique perms ina query
- up to 6 lookup
- indexed columns or folder for more
DB possède un moteur plus fin et scalable mais ne permet pas la richesse user de SP a voir les external lists avec BCS
Data in one big list
- folder and indexed
- lookup and reverse lookup
- consider sync to and from a DB
- many list peuvent avoir des droits plus fin et des champs supp
Tips and tricks
- connaissez vos queries
- toujours specifier view fields and where
- cross query are expensive
Sync list
- demande du travail
- 2 routes
- events
- instant update
- simple to code
- not transac
- change log GetListItmsChnges
Bien considérer la boite à outils SP entre foundation et server
Building blocks
- no code
- xml
- client object model rend le scenario plus flexible
- xsltListViewWebpart
- Sandboxed solutions
- use all tips from “nocode”
- RIA approche
- NO
- timer jobs
- WS calls
- impersonnation
- peut être étendue
- Full code
- kernel level of SP
- full trust WSP
- use for
- WCM
- quick control on dev
- custom field types
- dedicated farm
- Big App site
UI performance
- is all about performance
- Exp
- time to load
- time after 1 rst visit
- overall
- inf a 600 k
- request inf a 30
- 1 or 2 sql queries pr wcf, inf 5
- Smart client application= caching !!!
RIA : considerer le client comme le vrai frontend
Conclusion : oh la la quel sprint cette session, la première depuis longtemps qui a ete aussi intense en contenu, en rythme et en intensité, moralité, je n’ai pu prendre que70% du contenu par note
>>> clairement une des sessions que je vais rerererevoir et re analyser patiemment pour vous en faire de mini post tellement le sujet est riche et passionnant, enfin pour un archiDev :)
Renaud Comte aka TheMit ( épuisé par la session …)
Member of WygTeam
http://www.wygwam.com
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :