![\"\"](\"http:\/\/blogs.encamina.com\/desarrollandosobresharepoint\/wp-content\/uploads\/sites\/8\/2016\/09\/Inyecci\u00f3n-de-dependencias.jpg\")
<\/p>\n<\/p>\n
Una de las novedades que trae el nuevo FrameWork es que podemos saber cu\u00e1l es el entorno en el que se est\u00e1 ejecutando nuestro desarrollo<\/strong>. De esta forma, podemos ejecutar el WorkBench\u00a0en local, o bien en un Tenant de Office 365. A la hora de programar, es mucho m\u00e1s r\u00e1pido en un entorno en el que nos centremos en el desarrollo y no en pelearnos con autenticaci\u00f3n, seguridad, etc.. Por este motivo, en WorkBench o entorno de NodeJS, es muy importante \u00a0esta nueva forma de desarrollar. Crearemos Mocks de tal forma que podamos probar nuestros desarrollos de una forma desacoplada a SharePoint y agilizando el desarrollo.<\/p>\n <\/p>\n Todo esto esta suena muy bien, pero tal y como lo plantean en el ejemplo del Repositorio de GitHub<\/a>, en mi modesta opini\u00f3n,\u00a0no est\u00e1 bien enfocado,\u00a0<\/strong>ya que lo que hace es hablar de\u00a0\u00a0una duplicidad de m\u00e9todos. Esta duplicidad, en un \u00abHello World\u00bb se puede permitir, sin embargo, no es una buena opci\u00f3n materializarlo en proyecto real.<\/p>\n Por poner un s\u00edmil con un desarrollo en C#, no es lo mismo poner directivas de compilaci\u00f3n, \u00a0que hacer inyecci\u00f3n de dependencias<\/strong>. En JavaScript, aunque mucha gente lo desconozca, se puede hacer inyecci\u00f3n de dependencias. Por ejemplo, Angular utiliza mucho la inyecci\u00f3n de dependencias para su correcto funcionamiento.<\/p>\n Para desarrollar en SharePoint FrameWork, utilizamos un lenguaje\u00a0 TypeScript para\u00a0 aprovechar todo lo que nos da este lenguaje y simplificar el desarrollo. Por este motivo vamos a utilizar Interfaces e inyecci\u00f3n de dependencias en los constructores de las clases, de una forma muy similar a lo que hacemos en C#. La idea no es hacer de TypeScript un lenguaje como C#,<\/strong> sino intentar seguir los principios SOLID<\/strong> a la hora de programar y tratar de hacer bien las cosas.<\/p>\n Vamos a ver un ejemplo de c\u00f3mo plantear la soluci\u00f3n que comentan en el Repositorio de SharePoint, pero utilizando Inyecci\u00f3n de Dependencias<\/strong>. Por si alguien no se quiere leer el art\u00edculo del repositorio, lo que se hace en el ejemplo de GitHub es una parte en el entorno de Test, y otra\u00a0 dentro del Tenant de Office 365\/SharePoint Online. \u00c9sta, seg\u00fan mi opini\u00f3n, no es la forma correcta, ya que al ser dos \u00abcontratos\u00bb totalmente distintos, puede darse el caso que el c\u00f3digo de Test funcione, pero en Producci\u00f3n no.<\/p>\n Vamos a implementar ese \u00abContrato\u00bb para que nuestra aplicaci\u00f3n se comporte igual, tanto si est\u00e1s en Test, como si est\u00e1s en Office 365. Para ello, en primer lugar se implementa\u00a0una Interfaz que se encargar\u00e1 de hacer las consultas a SharePoint.<\/p>\n Nota:<\/strong> El atributo export<\/em>, es similar al public<\/em> de C#. El import<\/em>, es similiar a los using<\/em> de C#.\u00a0Una vez tenemos la interfaz, \u00a0vamos a crear dos clases que implementen esta interfaz. Por un lado, implementaremos una clase de Mock y por otro lado, implementaremos una clase con los accesos a SharePoint (para ello utilizaremos la librer\u00eda de PnP como veremos m\u00e1s adelante).<\/p>\n Clase MockSharePoint<\/p>\n Clase PnPSharePoint<\/p>\n Una vez implementadas las clases que vamos a utilizar, el siguiente paso es crear una clase (la que vamos a llamar en el arranque del WebPart, en la que nosotros le inyectemos el entorno en el que estamos). En C#, nosotros utilizar\u00edamos una herramientas como AutoFact, Unity, Castle, etc. En JavaScript hay FrameWorks que lo implementan de serie, como he comentado anteriormente. En nuestro caso, al NO utilizar ning\u00fan FrameWork, lo haremos de forma m\u00e1s artesana.<\/p>\n Para ello, implementaremos la clase Render, a la que llamaremos en el momento de la carga de nuestro WebPart:<\/p>\n Si os fij\u00e1is, en el constructor de la clase tiene dos par\u00e1metros: la Interfaz que hemos implementado y el elemento en el cual vamos a pintar el HTML.<\/p>\n Por \u00faltimo, lo que haremos en el m\u00e9todo Render del WebPart que estamos implementando, es crear una clase de tipo Render. Dependiendo del entorno en el que nos encontremos, crearemos una clase de tipo Mock o de tipo PnP. Quedar\u00eda de la siguiente forma:<\/p>\n En SharePoint, tradicionalmente a nivel de desarrollo siempre se ha criticado que los desarrolladores no segu\u00edan las buenas practicas ni recomendaciones del Lenguaje. En ocasiones se echaba la culpa a la propia peculiaridad de SharePoint. Sin embargo, esto no es excusa para al menos no intentar hacer las cosas bien.<\/p>\n Ahora, con el cambio de habilidades de los desarrolladores de SharePoint, no debemos\u00a0seguir con los errores del pasado y tenemos que seguir las buenas pr\u00e1cticas\u00a0 y recomendaciones del lenguaje que utilicemos. \u00c9ste es un caso de mala utilizaci\u00f3n del lenguaje y que apoya las palabras de los cr\u00edticos de SharePoint.<\/p>\n El c\u00f3digo fuente de este ejemplo lo pod\u00e9is encontrar en el siguiente repositorio de GitHub: <\/p>\n<\/span>","protected":false},"excerpt":{"rendered":" Una de las novedades que trae el nuevo FrameWork es que podemos saber cu\u00e1l es el entorno en el que se est\u00e1 ejecutando nuestro desarrollo. De esta forma, podemos ejecutar el WorkBench\u00a0en local, o bien en un Tenant de Office … Continue reading \r\nimport { ISPLists} from ".\/IList";\r\nexport interface ISharePoint {\r\n getList(): Promise<ISPLists>;\r\n}\r\n<\/pre>\n\r\nimport {ISharePoint} from ".\/ISharePoint";\r\nimport {ISPLists,ISPList} from ".\/IList";\r\nimport MockHttpClient from ".\/MockHttpClient";\r\nexport class MockSharePoint implements ISharePoint\r\n{\r\n Url:string;\r\n constructor(url:string){\r\n this.Url=url;\r\n }\r\n getList(): Promise<ISPLists> {\r\n return MockHttpClient.get(this.Url)\r\n .then((data: ISPList[]) => {\r\n var listData: ISPLists = { value: data };\r\n return listData;\r\n }) as Promise<ISPLists>;\r\n }\r\n}\r\n<\/pre>\n\r\nimport {ISharePoint} from ".\/ISharePoint";\r\nimport {ISPLists,ISPList} from ".\/IList";\r\nimport pnp from "sp-pnp-js";\r\n\r\nexport class PnPSharePoint implements ISharePoint {\r\nUrl:string;\r\nconstructor(url:string){\r\nthis.Url=url;\r\n}\r\n getList(): Promise<ISPLists> {\r\n\r\n return pnp.sp.web.lists.getByTitle("Documents").items.get().then((data: ISPList[]) => {\r\n var listData: ISPLists = { value: data };\r\n return listData;\r\n }) as Promise<ISPLists>;\r\n }\r\n}\r\n<\/pre>\n\r\nexport class Render{\r\nSharePoint:ISharePoint;\r\nRenderPrint: Element;\r\npublic constructor(sharePoint:ISharePoint, renderPrint:Element)\r\n{\r\n this.SharePoint=sharePoint;\r\n this.RenderPrint=renderPrint;\r\n}\r\n\r\npublic RenderList() {\r\n\r\n this.SharePoint.getList().then(\r\n (response) => {\r\n this._renderList(response.value);\r\n });\r\n}\r\nprivate _renderList(items: ISPList[]): void {\r\n let html: string = "";\r\n items.forEach((item: ISPList) => {\r\n html += `\r\n <ul >\r\n <li class="${styles.listItem}">\r\n <span class="ms-font-l">${item.Title}<\/span>\r\n <\/li>\r\n <\/ul>`;\r\n });\r\n this.RenderPrint.innerHTML = html;\r\n}\r\n}\r\n<\/pre>\n\r\n if (this.context.environment.type === EnvironmentType.Local) {\r\n this.fly= new Render(new MockSharePoint(this.context.pageContext.web.absoluteUrl),this.domElement.querySelector('#spListContainer'));\r\n }\r\n else{\r\n this.fly= new Render( new PnPSharePoint(this.context.pageContext.web.absoluteUrl),this.domElement.querySelector('#spListContainer'));\r\n }\r\n this.fly.RenderList();\r\n<\/pre>\nResumen<\/h2>\n
\n![\"github\"](\"http:\/\/blogs.encamina.com\/desarrollandosobresharepoint\/wp-content\/uploads\/sites\/8\/2016\/07\/github-1024x380.png\")
<\/a><\/p>\n