Consulte la documentación de mejores prácticas en disposing objects in SharePoint 2010 de Microsoft, sin embargo, hay opposing views.
Hay algunos puntos clave para proyectos de SharePoint:
- Siempre deseche sus SPWeb/SPSite objetos -> pérdidas de memoria
- Hacer uso de SPContext.Current ... cuando esté seguro el código se ejecuta en un contexto de SharePoint
- pruebas unitarias significan ningún contexto Sharepoint
- utilidades externas significan ningún contexto Sharepoint
- Powershell significa que no hay contexto de SharePoint (p. Ej. la activación de una función de receptor con función puede fallar)
- No tire SPContext.Current ... pero crear su propio objeto (de nuevo
using
)
Es posible que tenga problems with consistency con su SP múltiples objetos .. .
Al final SPSite site = SPContext.Current.Web.Site;
está bien en algunos casos, pero no tiene control sobre este objeto site
- ese podría ser el problema. Si opta por new SPSite(...)
, siempre tendrá suSPSite
y no algo que SharePoint haya creado y administrado para usted.
Personalmente, casi siempre uso la estructura using
para que todos los objetos se desechen correctamente después. Alternativamente, uso SPContext.Current.Web
sin desechar.
Tome un vistazo a una pregunta similar de mí: http://sharepoint.stackexchange.com/questions/20192/SPContext usando-corriente-o-usando-estático-url –
Gracias por el enlace. He actualizado mi pregunta. –
En proyectos más grandes a veces tiene utilidades externas que no se ejecutan en SharePoint. Otro ejemplo son las pruebas unitarias que tampoco se ejecutan en SharePoint. Si simplemente está desarrollando partes web visuales y no prueba la unidad, su código se ejecuta en SP. –