Evaluación de Sharepoint vs ASP.NET como una plataforma de desarrollo

Question

Estoy evaluando Sharepoint (no MOSS) frente a ASP.NET como una plataforma de desarrollo para una próxima solución para nuestro equipo. Desarrollaremos una solución para un despliegue amplio (esperamos) en una variedad de entornos. Estoy identificando categorías para evaluar pros/contras para cada opción de plataforma. Elegí categorías que se aplican a los requisitos de nuestra solución y que afectarán la productividad del desarrollador/evaluador. ¿Alguien puede pensar en otras categorías que serían apropiadas para una comparación? ¿Alguien puede proporcionar detalles sobre sus experiencias con las dos plataformas con respecto a cualquiera de las categorías?

Alguna otra información, tenemos un corto marco de tiempo de dos meses para lanzar algo, por lo que estamos priorizando las características en estos momentos. Vemos a Sharepoint como una forma de sacar algo rápidamente, aprovechando el marco de la interfaz de usuario para una interfaz de usuario básica, seguridad y listas y bibliotecas de documentos para el almacenamiento.

entorno de desarrollo

la productividad del desarrollador

Comprobabilidad funcional

desarrollador Capacidad de prueba (pruebas unitarias)

basado en roles de seguridad

basada en Ver seguridad

Experiencia del usuario

Base de datos - Fácil de desarrollar con Sharepoint basado en el uso de listas. Sin embargo, agregar informes como requisito hace que el uso de listas sea un obstáculo.

de informes - Sharepoint hace que esto sea difícil Repositorio

Documento - Nuestra solución requerirá múltiples bibliotecas de documentos para conectar artefactos a elementos de la solución

Embalaje

Instalación - Sharepoint nos proporciona la instalación famr fácil a través del PSA .

Escalabilidad

extensibilidad

Complejidad

conceptuales Integrity (los límites del dominio)

redundancia Soporte/Replicación/Copia de seguridad/Recuperación

Answer 1

Oficialmente, con el fin de desarrollar soluciones WSS, todos sus desarrolladores necesitarán tener su entorno de desarrollo ejecutado en un servidor WSS. Considero que es un negativo.

Ver los comentarios muchos en Sharepoint tools support in Visual Studio por Somasegar.

Diría que, dado que tiene una fecha límite corta, también considera el hecho de que hay una comunidad de desarrolladores de SharePoint mucho más pequeña que una comunidad ASP.NET. Compare la cantidad de artículos sobre SO etiquetados con "ASP.NET" en comparación con aquellos etiquetados como "SharePoint".

Me gustaría ir con ASP.NET en el corto plazo, entendiendo que es posible que pueda refactorizar su aplicación para usar SharePoint a largo plazo. Use una estructura de base de datos similar a la lista u otros tipos de contenido que habría creado en SharePoint. Mantenga un modelo de implementación similar. Siéntase libre de usar el flujo de trabajo, pero probablemente debería ser paralelo a las características del flujo de trabajo de SharePoint. Incluso podría diseñar sus páginas de manera similar. Esto hará que sea más fácil moverse a SharePoint cuando tenga más tiempo.

Answer 2

no veo costo.

Answer 3

¿Su solución va a tener algo que ver con la colaboración o la administración de contenido web? De lo contrario, agregar SharePoint a la mezcla no va a ser una gran idea.

El uso de WSS 3.0 como plataforma de desarrollo en lugar de ASP.NET requeriría una justificación seria y no es posible contar, por su descripción limitada de la solución, por qué siquiera lo contemplaría.

En todos sus aspectos de medición, la creación de desarrollo en la plataforma de SharePoint agregaría coplejidad y, por lo tanto, costará a cualquier esfuerzo de desarrollo.

actualización

veo la seguridad de Sharepoint, bibliotecas de documentos, el marco de interfaz de usuario, y la falta de necesidad de construir y prueba de una base de datos tan grande una productividad reforzadores. Esos son Sharepoint características que pueden beneficiarse en gran medida de

Los beneficios de SharePoint para esos artículos son muy inferiores a los aspectos de costos de aprendizaje, codificación y SharePoint apoyo. ASP.NET tiene soluciones fáciles para estos artículos y de una manera mucho más manejable. Después de haber utilizado ambos productos tendrá que quedarse con ASP.Net

Recuerde que las listas de SharePoint no tienen ningún tipo de integridad relacional por lo que crear nada más que una relación trivial entre las listas de SharePoint terminará masivamente más caro que creando una instrucción de combinación y algunos procesos almacenados.

Sin conocer más detalles del proyecto, no puedo descartar completamente SharePoint como una solución.

Si bien es posible usar SharePoint como una plataforma de desarrollo, si no tiene expertos de SharePoint trabajando con usted que puedan responder su pregunta, no tendrá suficientes habilidades de SharePoint en su proyecto para que sea un éxito.

Answer 4

escalabilidad
Restricciones de la licencia
extensibilidad
Complejidad
conceptuales de Integridad (límites de dominio)
vendedor Lockin/Sistemas de soporte abierto
Redundancia/Replicación/Copia de seguridad/Recuperación de Apoyo

Answer 5

Usamos SharePoint como un componente para la mayoría de las aplicaciones que creamos para su capacidad de crear y administrar listas y tipos de contenido (y CRUD automático), control de versiones, modelos de permisos y herramientas de flujo de trabajo.

Desarrollamos SLAM, el Administrador de asociaciones de listas de SharePoint, para superar las limitaciones obvias en términos de que los datos de SharePoint no son relacionales. Debido a que impulsa los datos de SharePoint a SQL Server, nos permite usar SharePoint solo en el "back-end" con solo ASP.NET en el front-end, una configuración que usamos a menudo.

Hemos lanzado SLAM como un proyecto de código abierto para que el resto de la comunidad de desarrollo pueda aprovechar este enfoque y ayudarnos a ampliarlo.

http://slam.codeplex.com

feliz pirateo!

Allan