Variante al acceder UserPofileManager vía código en SharePoint 2010

 

Para obtener los perfiles de usuario de SharePoint Server utilizamos la clase UserPofileManager y en 2007 pasábamos una instancia de la clase ServerContext que representaba los servicios compartidos de SharePoint 2007 o SSP.   Pero en 2010 ya no existe mas SSP ahora cada servicio es independiente del otro y esto también afecta la forma en que escribimos el código en 2010. 

Ahora cuando deseamos utilizar la clase ServerContext en 2010 a través de el ensamblado Microsoft.Office.Server.dll nos muestra la imagen de abajo::

Y cuando la pasamos al UserProfileManager también nos previene que ya es una sentencia obsoleta.

Y nos indica que utilicemos la clase SPServiceContext.

Entonces la nueva forma de hacerlo no varía mucho de la anterior pero si tiene un impacto importante en los recursos utilizados y en el tiempo que demorará la solicitud de nuestro código.

Ejemplo completo de la forma en que se hacía en  2007 :

La nueva forma de hacerlo sería la siguiente:

PropertyConstants es una clase que nos permite acceder los campos de los perfiles de usuario no importante el lenguaje con que esta instalado SharePoint y esta disponible en ambas versiones y es mejor utilizarla en vez de utilizar un string que varía de versión del lenguaje en que esta instalado SharePoint, ya que en inglés sería “WorkEmail” y en español “Correo del Trabajo”, por ejemplo.

La recomendación será que nuevos desarrollos o en los cambios que necesitemos hacer vayamos migrando el código dejando de utilizar ServerContext y ahora utilizar SPServiceContext.

Hasta la próxima!, SharePoint4Fun!,

Manolo Herrera

Este nuevo año me trajo un nuevo y liviano contenedor de control de inversión para SharePoint

Hace algún tiempo estaba con la intención de desarrollar un IoC (Inversion of Control) o DI (Dependency Injection) para el desarrollo de elementos Web dentro de SharePoint, anteriormente lo hacía manual el acoplamiento da cada uno de los elementos, pero este descanso de fin de año me sirvió para desarrollarlo finalmente. Y estoy satisfecho de lo realizado.

Es muy liviano solo ocupa 10 Kb (Lo he publicado en codeplex para contribuir con la comunidad tecnológica y lo bautice como IoC4Fun) y consta de 2 clases el contenedor y el Registrador o TypeRegister como le llama a la clase que registra las dependencias dentro del contenedor.

Quiero agradecer a la contribución de Ken Egozi por si su artículo sobre construir un contenedor en 33 líneas en 15 minutos me sirvió de ayuda para desarrollar mi propio contendedor de inyección de dependencia. 

A diferencia de Ken le invertí un poco de mas de 15 minutos y el resultado fue una herramienta muy liviana, que hace lo necesario y no estoy pegado a ninguna plataforma o framework fuera del .Net framework 3.5. 

A continuación enumeraré las funcionalidades que fluí agregando:

En vez de utilizar un diccionario para registrar los tipos, utilice una lista genérica de tipo TypeRegister.

Agregue la funcionalidad para localizar las propiedades y no solo parámetros del constructo y que resolviera las dependencias basado en parámetros definidos al momento de ser registrados.

Agregue la opción Share para compartir la misma instancia entre dependencias.

Que el contenedor aceptara una la instancia de una clase ya creada en memoria necesaria para aplicar el patrón Passive View al momento de inyectar la instancia de la página en el presentador.

Y por último agregué la opción para no buscar ninguna dependencia (DisposeAll) o que permitiera dependencias nulas por si una propiedad no fuese requerida o es parte de la lógica de la clase que la contiene (AllowNull).

Al final tenemos una resultado elegante, práctico y fácil de implementar:

Algo que me agrado fue que no agregue código intrusivo a las dependencias aunque con sus respectivas limitaciones que no afectan para las soluciones que desarrollo como la limitación de solo tener un constructor para que sepa como resolverlo el contenedor.  Pero gané un código muy limpio como muestro en la imagen de abajo:

Otra buena funcionalidad fue revisar que no se registrará mas de una vez un los mismos tipos, a través de Linq fue algo muy sencillo.

y la posibilidad de definir diferentes implementaciones de una misma interfaz como el caso del Logger en el ejemplo:

Bueno amigo lector le pido viste codeplex el proyecto IoC4Fun y hágame llegar sus comentarios.

Contribute4Fun!,

Manolo Herrera