The Mit's Blog

#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
  • hard to write
  • full wcf

>>> 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
• perf penalty
• Full code
• kernel level of SP
• full trust WSP
• use for
• WCM
• quick control on dev
• custom field types
• dedicated farm
• Big App site
• need full WF
• full option

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