Algunas alternativas más baratas a MOSS y que pueden servir para pequeños grupos de trabajo que no necesiten todas las capacidades de este producto:
Otra cosa es que cada uno encuentre lo que busca en cada una de estas ofertas y cómo de complicado sea customizarlos y hacer que estos productos se ajusten a las necesidades de cada empresa, que variarán mucho en función de tamaño, necesidades documentales, requisitos legales, etc.
El equipo de MOSS nos detalla y concreta los updates para una actualización completa de un entorno MOSS. Los distintos paquetes y el orden en el que deben ser actualizados. Igualmetne tienen el detalle de indicar el número de versión resultante (12.0.6504.5000), muy útil para conciliar problemas que pueda haber con operaciones de backup / restore.
El artículo aquí.
Con las sucesivas versiones del MVC para asp.net que vienen apareciendo desde Octubre del 2007, el equipo de Scott Guthrie nos ofrece un framework que trasciende el modelo de eventos al que estamos acostumbrados, y nos ofrece varias ventajas nuevas, que para ser aprovechadas nos obliga a cambiar el modo de desarrollar habitual de asp.net.
No obstante, las ventajas son muchas:
- Separación clara de dónde tiene que ir cada tipo de lógica (separation of concerns). Esto nos facilita el mantenimiento y la escalabilidad de la aplicación, además de facilitar el desarrollo en paralelo de las distintas partes o módulos.
- Suporte al desarrollos por medio de metodología TDD por defecto (Test Driven Development). Por tanto facilidad para crear mock tests y para poder correr los tests desde fuera del proceso de asp.net. Gran diferencia con respecto a como se tenían que hacer las pruebas anteriormente, o bien a mano, o bien con torpes y complejas macros para disparar eventos en la interfaz.
- Arquitectura “pluggable” y extensible, en la que los componentes pueden ser aumentados o extendidos, algo que ya se podía hacer en las versiones anteriores de asp.net, pero que ahora va más allá. Ahora podemos usar inyectores de dependencia como Castle Windsor, Spring.net o Unity.
- Motor de routing (asociación de una URL concreta con el controller correcto) para tener url más legibles, al estilo REST.
- No hay ViewState ni ciclo de vida de las páginas. Menos peso, menos complejidad.
- Control total del HTML generado. No tenemos controles que añaden su propio markup. Esto nos permite ademas integrar más fácilmente librerías como JQuery o MooTools, y olvidarnos de todo el código que asp.net inyecta para el mantenimiento del estado y el ViewState.
Conviene recordar que MVC no suplanta o elimina el desarrollo “tradicional” mediante webforms. Se trata simplemente de una alternativa que hay que sopesar según la situación y el tipo de proyecto. No olvidemos que asp.net webforms nos ofrece también un modelo de eventos familiar a todos los desarrolladores, mantenimiento del estado entre requests, numerosos controles de otros vendedores. No se trata de despreciar ahora este estupendo modelo de desarrollo.
Es necesario, por tanto, escoger el modelo en cada caso. Asp.Net MVC nos viene bien, o no, si queremos
- Desarrollar según TDD.
- Necesitamos controlar el HTML generado completamente.
- Operaciones atómicas que no necesitan estado entre peticiones. Si la aplicación es muy orientada a datos y necesitamos estado, no es la opción adecuada.
- Podemos prescindir de los eventos o sustituirlos mediante javascript y invocaciones web via ajax.
- No es la opción adecuada si tenemos que usar controles ya generados o crear prototipos rápidos mediante drag & drop. Para eso, mejor webforms.