El tendón de Aquiles de DotNetNuke (DNN)
Conste antes de nada que me considero defensor acérrimo de DotNetNuke. No obstante, en según qué casos, elegir este CMS pueda que no sea la mejor opción.
Llevo cerca de año y medio usando DNN y como todo, tiene sus cosas buenas y sus cosas no tan buenas. Sin embargo, hay dos puntos que para mí son especialmente críticos en DNN. Dos problemas que conviene tener en cuenta antes de decirnos por este...
Conste antes de nada que me considero defensor acérrimo de DotNetNuke. No obstante, en según qué casos, elegir este CMS pueda que no sea la mejor opción.
Llevo cerca de año y medio usando DNN y como todo, tiene sus cosas buenas y sus cosas no tan buenas. Sin embargo, hay dos puntos que para mí son especialmente críticos en DNN. Dos problemas que conviene tener en cuenta antes de decirnos por este CMS.
1.- Necesitaremos Keep Alive.
Como ya sabrás, las webs desarrolladas con ASP.NET, cuando llevan un tiempo sin ser visitadas se sumen en un letargo. Lo positivo de esto, es que dichas Webs dejan de consumir recursos. Lo negativo, es que la primera carga, por parte de un navegante, se hace insufrible ya que el sitio tiene que “despertarse”.
Si al igual que yo, has desarrollado Webs desde cero usando ASP.NET, seguramente estarás familiarizado con el concepto de pre-compilación, pues bien, DNN no se lleva bien con esto (incompatibilidades con los recursos de idioma creo recordar). Como alternativa, verás que te recomendarán usar diferentes métodos de Keep Alive, métodos, que como su nombre indica, se dedicarán a despertar una y otra vez a la Web en cuestión. Es decir, aunque tu Web no sea visitada por nadie, ésta consumirá recursos.
Como te puedes imaginar esto puede ser un grave problema, ya que podemos encontrarnos con la contradicción de que páginas que tienen apenas 5 visitas al día, comen recursos de manera continuada.
Para mí, desde siempre, una página sin visitas es una página que casi no consume. Con DNN, esto no es así.
2.- Permisos del usuario de Base de Datos.
Otro problema a tener muy en cuenta son los permisos del usuario de Base de Datos con el cual se ejecuta la aplicación. Como leerás en muchas páginas,
se supone, que no son necesarios permisos de propietario para hacer funcionar un DNN. Lo cierto, es que a día de hoy, no he sido capaz de hacer un funcionar un DotNetNuke al 100%, sin establecer a dicho usuario permisos dbo. Debo añadir, que
hace tiempo que no lo intento.
Esto no sería un problema, si no fuera por el hecho de que servidores compartidos de la importancia de Arsys, se niegan en rotundo a otorgar tales privilegios, alegando cuestiones de seguridad.
Coméntale a un cliente que no va a poder usar el servidor compartido que tiene contratado con Arsys desde hace años y después me lo cuentas que seguro que es gracioso.
Con todo lo dicho, no quiero desanimar a nadie a usar DNN, tan sólo advertiros de los problemas que os podríais encontrar si seleccionáis este gran CMS. Por experiencia os digo que puede ser muy desagradable desarrollar una Web al 100% y descubrir, a posteriori que no puede ser alojada en un servidor compartido como hostalia.
Nos vemos
Nota: Desconozco si las últimas versiones de DNN (5.X) corrijen lo dicho en este documento.