Pregunta

Tenemos varios proyectos con muchos DAL. Muchas listas de SharePoint como clientes, ventas, proveedores que reflejan en las clases de C#. Hacemos que cada objeto implementa idisible a través de una clase de madre abstracta. Y cada vez que instanciamos un objeto para obtener un cliente de una lista, por ejemplo, el código de la persona que llama debe llamar a Customer.dispose () para deshacerse de los SPWEB y SPSITE utilizados para instanciar el objeto:

 public Customer(int spListItemID):base(LIST_URL)
    {
        try
        {
            spli = Liste.GetItemById(spListItemID);
        }
        catch(ArgumentException)
        {
            spli = null;
        }
    }

Y en la clase base del constructor hay variables globales SPSITS y SPWEB instanciadas y también existe la función de eliminación.

Me preguntaba: ¿Qué tal usar los mismos SpWeb y SPSITE para toda la aplicación de SharePoint? Todos nuestros proyectos conocen un proyecto que podría instanciar esos SPSITS y SPWEB después de un patrón de singleton. Y usaríamos este SPSIT y SPWEB "Forever", ¡nunca los cerraríamos a ambos y usaríamos lo mismo para cada objeto, guardando el proceso de cierre de apertura cada vez que instanciemos un objeto!

¿Crees que es una idea loca, que tendría repercusiones? Me refiero a usar el mismo spweb durante mucho tiempo, es decir, el tiempo que está en el servidor ... ¿es una mala idea? en lugar de abrir el cierre de SPWeb miles de tiempo por día por cada instancia? ¿Spweb tiene un período vivo limitado? (Es una gran aplicación de SharePoint con mucho desarrollo)

¿Fue útil?

Solución

El mayor riesgo es que el spweb podría volverse obsoleto. En un entorno de múltiples usuarios, las propiedades de SPWEB que se obtienen en el primer viaje de ida y vuelta (por ejemplo - Título web) pueden ser cambiados por otro usuario, pero continúa teniendo los valores antiguos ya que no está instanciando de nuevo. Puede crear múltiples instancias de SPWEB y SPSITE siempre que los elimine correctamente.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top