¿Qué dirección deberíamos seguir para mantener un sistema de administración de documentos?

Hemos creado una aplicación sobre ASP.NET MVC. Ahora debemos permitir que nuestros usuarios administren sus documentos en línea. Como parte de este sistema, los usuarios desean cargar y compartir documentos con otros miembros de su organización.

Tenemos una aplicación web existente que necesita esta funcionalidad como un valor agregado. Estamos tratando de descubrir cuáles son nuestras opciones para satisfacer esta necesidad. En última instancia, estamos buscando una solución de back-end que nos ayude con gran parte del trabajo pesado asociado con el control de versiones. El acceso a los documentos aún debe mantenerse a través de nuestro model de dominio y la interfaz de usuario web.

Necesitamos ser capaces de …

  • upload documentos
  • ver el historial de versiones de cada documento
  • realizar búsqueda de text completo
  • calcular el tamaño del file

Estamos considerando:

  • build nuestro propio model de dominio y almacenar documentos en una database
  • integrando con subversion para usarlo como nuestro back-end.

¿Qué enfoque ha funcionado para ti? ¿Cuáles son algunos de los beneficios y desventajas de cada uno? ¿Hay otras alternativas?

La solución que elijamos debe cumplir con los siguientes criterios:

  • debe encajar perfectamente en nuestras implementaciones automatizadas.
  • necesitamos poder ejecutar la aplicación en nuestras máquinas locales de desarrollo, sin necesidad de una connection a un server separado
  • nos gustaría algo ligero, y fácil de actualizar y desplegar

Subversion suena como la mejor apuesta aquí, simplemente entrene a los usuarios que tienen que administrar los documentos sobre cómo usar TortoiseSVN y luego haga que su almacenamiento de documentos sea un subdirectory de su proyecto.

¿Has mirado a Sharepoint que es básicamente lo que estás describiendo?

Optamos por build nuestro propio model de dominio y almacenar documentos en una database de SQL Server 2008. Hasta ahora, esto ha funcionado muy bien para nosotros.

¿Por qué no usar subversión con uno de los muchos clientes que podrían satisfacer sus necesidades de la caja?

Si lo estás construyendo tú mismo y usando C # y SVN, sharpSVN parece una buena solución. Con acceso completo a la API SVN Client, usted podrá felizmente poder integrar la aplicación web a un backend SVN. Aplicando security por properties SVN o algún otro almacén de metadatos.

Algunos de los problemas que puedo ver son:

  • Si tienes varios sitios, puede ser difícil conseguir diferentes SVN Repos para jugar bien cuando tienen que sincronizar (si es necesario).
  • SVN no hace mucho más que almacenar blobs binarys, por lo que solo versionará los objects y no podrá ofrecerle diffs. Esto puede conducir a una database SVN muy grande.
  • Actualmente, tampoco es posible purgar un file de un repository, lo que también generará grandes repositorys SVN.
  • Si diferentes personas pueden revisar documentos, y esperan que sean diferentes "twigs" del documento, entonces puede ser mejor utilizar un model de control de fuente distribuida donde tales cosas son más fáciles.

Aunque sería bueno reutilizar algo como Subversion en el server, hace que la implementación de la aplicación sea más complicada. Si está contento con esto, entonces sharpSVN (como lo sugiere Andrew Cox) parece una buena opción.

Si está less preocupado por algunos de los aspectos de control de versiones de Subversion (diffs y branches), entonces estaría tentado de unir un module de administración de documentos rápido a su aplicación existente.

Usaría Lucene para manejar las cosas difíciles: indexing y búsqueda de text completo.

Si yo fuera usted, investigaría Sharepoint, o al less los services de Sharepoint Portal. Este es precisamente el escenario que aborda la solución