Desarrollo WSS / MOSS & # 8230; Donde dibujar la linea?

Question

Nuestra organización comenzó en la ruta de SharePoint hace aproximadamente dos años. Antes de eso, nosotros (los desarrolladores) escribimos principalmente front-end asp.net para back-end SQL. Ahora parece que cada vez que surge un nuevo proyecto, se nos pide & # 8220; hacer & # 8221; cabe en SharePoint; y hemos incluido algunas cosas en SharePoint que probablemente deberían haber sido aplicaciones independientes o aplicaciones web debido a la complejidad e interacciones con otras tecnologías.

Mi pregunta es: ¿dónde traza la línea para desarrollar un proyecto en SharePoint versus la aplicación Web / Winform, y cómo convence a sus gerentes de que SharePoint puede no ser la mejor solución para un proyecto en particular?

Answer 1

Estoy de acuerdo con usted en que a veces es una pregunta difícil. Sin embargo, en general, estoy de acuerdo con el cliché de que solo tienes que pensar en una aplicación sharepoint de manera un poco diferente. Si sus datos pueden considerarse como basados ??en listas, entonces SharePoint probablemente no sea necesariamente un mal marco de desarrollo. Puede parecer más trabajo en la superficie, pero IMO los desafíos simplemente se mueven de un lugar a otro. Si usa elementos como plantillas de campo personalizadas y elementos web, puede manejar de forma relativamente natural todo tipo de datos. Y obtiene los aspectos positivos de SharePoint de forma gratuita (un marco de seguridad ya maduro, búsqueda integrada, plantillas / definiciones de sitios y listas, personalizaciones de páginas personalizadas, yada, yada).

Tampoco sé a qué te refieres con "complejidad e interacciones con otras tecnologías". aquí, así que es difícil imaginar qué problemas específicos podrían introducirse cuando se agrega SharePoint a la mezcla.

Si su equipo de desarrollo es relativamente inexperto con SharePoint y le preocupa la calidad y los plazos, definitivamente puedo ver su punto. No es una curva de aprendizaje fácil, pero creo que el producto de SharePoint es más extensible de forma natural de lo que muchas personas le dan crédito.

Answer 2

Hay, en algunos casos, una tercera opción entre una aplicación de SharePoint y una aplicación ASP.NET. Puede crear páginas personalizadas de sitios y aplicaciones e implementarlas en un sitio de SharePoint. (El libro Inside Windows SharePoint Services 3.0 ofrece una buena descripción general de cómo hacerlo). Esto le permitirá usar ASP.Net y SQL Server dentro de un entorno de SharePoint (lo que significa que también puede aprovechar cosas como la seguridad de SharePoint). No es tan fácil como desarrollar una aplicación ASP.Net simple, pero es un compromiso.

Por supuesto, esto es una especie de tecnicismo si quieren que estas nuevas aplicaciones se construyan sobre tecnologías de SharePoint (listas, bibliotecas, flujo de trabajo, etc.), no solo para estar "dentro". SharePoint.

Answer 3

Una de las razones principales por las que puede poner una aplicación en SP es cuando desea aprovechar los componentes básicos que SP le brinda:

• Seguridad (compartir seguridad con el sitio)
• Datos (almacene algunos o todos sus datos en listas)
• Aprovisionamiento (si desea su aplicación en varios sitios)
• Algunos IU de datos básicos, p. Las listas te dan eso y no necesitas construirlo.

Answer 4

Una cosa a tener en cuenta al intentar 'integrar' una nueva aplicación en el grupo existente es si existe una superposición de datos (clientes, inventario, etc.) que se beneficiarían de la fusión.

También existe la ventaja de poder realizar copias de seguridad de múltiples aplicaciones y todos sus datos respectivos en un solo lugar.

Answer 5

¿Por qué piden que todo vaya a SharePoint?

En mi experiencia, es porque la intranet de 'ole SharePoint está siendo excelente como un portal para mantener todo junto y encontrar bajo la única arquitectura de información.

Aborde el problema desde una percepción de usos del espacio de aplicación en la organización.

Mientras la aplicación se vea y se sienta como parte del sitio de intranet y el usuario no tenga que pensar en cómo acceder (y cómo salir), puede tomar las decisiones de arquitectura necesarias para obtener el mejor rendimiento de las organizaciones cuando se trata de implementación y mantenimiento.

Cuando comenzamos a pensar menos en el sitio, desde SharePoint frente a otras cosas, hasta los agradables conceptos de arquitectura de la información, facilidad de uso y facilidad de uso, nuestras decisiones de no hacerlo realmente dentro de SharePoint, sino aún desollarlo como la Intranet se hizo más fácil de vender .