Para SharePoint O no (como una base para el desarrollo de aplicaciones) (vs ASP.NET)

Question

Tengo un POV que solo debe usar SharePoint para el desarrollo de aplicaciones bajo estas condiciones.

1) La aplicación utiliza documentos y estos documentos necesitan algún tipo de funcionalidad que SharePoint hace extremadamente bien (búsqueda/indexación, sincronización con Outlook, etc.) Si todo lo que desea es un contenedor de documentos y una lista, entonces ASP .NET o ASP.NET MVC.

2) La aplicación debe usar flujos de trabajo o flujos de trabajo personalizados. Sin flujo de trabajo, volvería a mirar hacia ASP.NET o ASP.NET MVC.

3) La empresa debe estar dispuesta a dedicar al menos 1 desarrollador de tiempo completo a SharePoint. No es 1/2 o un 1/3 de un desarrollador. Necesita compromiso y enfoque para hacer el desarrollo de SharePoint correctamente. Debes beber el Kool-Aid. Si no está dispuesto a especializarse en SharePoint, pero solo está dispuesto a incursionar, las soluciones resultantes son terribles (en mi humilde opinión). Aún mejor si puede dedicar dos desarrolladores o un equipo (piense en compatibilidad/mantenimiento/especialización/especialización).

¿Qué opinas?

nota: Creo que todas las tiendas de Microsoft deberían usar las características listas para usar de SharePoint si su compañía ha elegido vincular eso con Exchange como parte de su arquitectura de colaboración. No soy anti-SharePoint.

ACTUALIZACIÓN
Después de sentarse en un taller SP He aprendido que SharePoint flujo de trabajo sólo se aplica sobre una base por elemento de la lista de SharePoint. Por lo tanto, si su flujo de trabajo no utiliza elementos de la lista de SharePoint, entonces probablemente debería mirar la base de flujo de trabajo de .NET o algo personalizado. Considere esto como un reemplazo de mi artículo # 2.

Answer 1

Estoy de acuerdo. Sharepoint actualmente (moss 2007/wss 3.0) hace del desarrollo personalizado un proceso muy doloroso y lento. El único punto con el que estaría en desacuerdo es la porción del flujo de trabajo. En mi opinión, el flujo de trabajo en SharePoint es casi inutilizable y debe evitarse. Si vas a hacer flujos de trabajo, ve por k2: blackpearl o MassTransit para la opción libre de código abierto.

Answer 2

Digamos que tiene un almacén de datos que recopila datos de muchos puntos de la empresa. Es de esperar que tenga unas dimensiones que tengan personas de negocios designadas como "propietarios de dimensión". Estas son las personas que tienen interés en la organización de datos en la dimensión. Son responsables de mantener las jerarquías y listas al día, pero estas colecciones no están pobladas con datos de operaciones que provienen de sistemas transaccionales, son términos comerciales, grupos y descripciones que habla la empresa. Este es su lenguaje comercial natural. East Sales Team, Small Business, High Risk, Print-Ad Promotion 25, etc. El punto es que su data warehouse se construye con un 99% de operaciones/material transaccional, pero son los arreglos comerciales los que hacen más sensato para sus usuarios y usted necesita un lugar para capturarlo

Sin duda puede hacer una aplicación web. Puedes usar un archivo de Excel. Lo que sea. Pero también puedes usar una lista de SharePoint. Cuando SharePoint es atractivo para esto es cuando el entorno ya existe (y, por lo tanto, SOPORTA), cuando sus requisitos no son extensos, es decir, no se requiere integridad referencial, no tiene los recursos para crear una nueva aplicación web, los usuarios comerciales ya están familiarizados y cómodos con SharePoint, lo necesita ayer, etc.

Así que no estoy hablando aquí de escribir código y compilar bibliotecas para instalar en SharePoint. Solo estoy tratando de presentar un "momento y lugar correctos" razonables para que se use.

BTW - Aquí hay una muy útil how-to on pushing and pulling data between SharePoint lists and SSIS.

Answer 3

SharePoint se debe utilizar como base para la colaboración empresarial de los usuarios (es decir, almacenar, encontrar y editar documentos entre sí). Usar SharePoint simplemente para el desarrollo de aplicaciones duele y requiere el punto 3 hecho en la pregunta.

Para Desarrollos aplicación, yo prefiero usar SharePoint como un portal web que dirige a los usuarios a la aplicación o recibe su interfaz web (a través de controles de usuario, webparts y similares) (oh espera, todo lo listo dije SharePoint era una tela portal).

Answer 4

Incluso sin documentos, aún puede usar Sharepoint como una plataforma para un portal con partes web personalizadas (tal vez algunos de ellos se basan en bibliotecas de documentos del sitio). Es una buena plataforma de portal y el portal de investigación de mi empresa se basa en compartir, y funciona bastante bien. Lo bueno es que con este portal sharepoint basado en webparts, aún puede ocuparse de los problemas de permisos y de la personalización de la presentación (arrastrar el sitio web a una zona en particular, etc., que los usuarios hacen mucho, por cierto) con relativa facilidad. Además, las partes web de tipo WSRP funcionan bastante bien con Sharepoint.

Y tiene razón, solo si tiene buenos desarrolladores de Sharepoint, entonces le facilita las cosas y es una plataforma decente, documentos o ningún documento.