05 agosto 2005

 

Ya veo la meta (provisional) para letrasenlared.com

Hoy es viernes, y el pasado lunes comencé a saco con letrasenlared.com... han sido cuatro días al máximo, y he hecho más que lo que había hecho hasta ahora en varios meses.

El lunes comencé con muchas ganas, aunque no con todo el tiempo que quisiera; yo le calculo unas cinco horas de trabajo, sólo con las capas DAL y BLL. Dejé terminada las clases dedicadas a la categorización de contenidos.

Como va a ser norma general (y esto lo pienso hoy viernes, pero el lunes no lo tenía claro), todo lo que haga va a poder ser reutilizado en un futuro, y lo de la categorización es cojonudo, porque categoriza todo lo que quieras... por lo menos todo lo que se me ha ocurrido categorizar durante todos mis años de webmaster (aficionado).

Me explico con ejemplos prácticos: en letrasenlared.com han de haber categorías según los géneros literarios (poesía, teatro, prosa, relatos, cuentos), y para cada uno han de haber subcategorías (cuentos fantásticos, cuentos infantiles, etc.). Pero además, también han de haber categorías para los foros y subforos (foro de escritores, foro de libros, foro de la madre del topo) o para las noticias de la página principal (noticas de actualidad, cambios en la web, mundo literarios, etc.).
Y no sólo eso, en discotequeros.com también me viene muy bien lo de la categorización, ya que a parte de noticias y foros, también hay zonas de discotecas para la guía de discotecas, esta la sección de infofiesta, categorías para las fotos, y un largo etc.

Vamos, es como un árbol y sus correspondientes ramas y hojas, y la tabla de la BBDD es tan sencilla que me da hasta vergüenza que el lector crea que para mí es algo novedoso; he aquí:
- Id: es la clave primaria, y es un string... sí, ya sé que hacer clave primaria a un string es algo dudosillo, pero en la BLL me aseguro de que es único. Además no suele ser demasiado largo, por lo que no pierde demasiadas cualidades como índice. Y lo hago string para optimización de buscadores (esto es otra historia).
- Madre: no hace falta saber mucho para imaginarse que la madre es la id de la rama superior. Por cierto, la parte más alta del árbol se llama "madre" (qué original, ¿no?)
- Título: pues eso. Por cierto, Id es una googlelización del titulo.
- Descripción: en ocasiones es necesario, si no lo fuera no hace falta ponerlo.
- Visibilidad: esto es una historia propia que me ha sido aconsejada por mi experiencia de tantos años de webmaster (aficionado). Así no tengo que borrar categorías, simplemente las oculto... por si acaso.
- Prioridad: 1 máxima (más arriba), 200 mínima. Es un tinyint, por lo que SQLServer ni se entera.

Pues lo dicho, la tabla no es demasiado complicada, lo que sí es algo más elaborado es la BLL y la DAL. La BLL porque propone una serie de funciones superinteresantes y que van a ser utilizadas en mucho lugares, y sólo hace falta escribirlos una vez (como me gusta la OO); y la DAL pq es megaóptima y muy rápida.

Pues eso fue el lunes, así que pa cagarse, porque esto ya me sirve para toda la vida.

En cuanto al martes, jueves y viernes (el miércoles tuve un día movidito: piscina, regalo a mi niña, Fosters con mis padres, cine, ver el fútbol con los colegas y algo de mi enemiga la PS2; vamos que no entré en mi casa), he estado trabajando con el foro... bueno, mejor dicho, he estado trabajando con TodoPub.

Me explico, TodoPub responde a la misma manía de generalizar varias cosas similares. Hasta ahora, en mis webs tenía una tabla de la BBDD para el foro, otra para el libro de visitas, otra para las fotos, otra para las noticias y así hasta que la muerte nos separe. No hace falta ser un genio para ver que todas esas entes responden a una estructura análoga, ya que todas tienen: Id, Título, Autor, Texto, Fecha y otros 7 campos... y esto no me lo he inventado yo, y si no que se lo pregunten a RSS o al resto de "estándares" de sindicación.
Pues eso, todas los módulos de letrasenlared que me sea posible los endosaré a TodoPub. Por ejemplo el foro, las noticias e incluso las obras publicadas.
Del mismo modo que con la categorización, la tabla es sencillita, lo que es más complejo son las capas BLL y DAL.

Me lo he currado en la DAL pq la magia de ADO.NET permite operaciones hiperrápidas, aunque claro, lo tienes que implementar, y aunque realmente no cuesta casi nada, el exceso de comodidad (o falta de conocimiento), puede hacer que no nos aprovechemos de ellas. Pero bueno, es el pan nuestro de cada día: siempre es más fácil ejecutar una sentencia SQL desde la UI sin más que copiar y pegar, que seguir un proceso más elaborado que paso a comentar dada su importancia:
1º Enlazar la UI con la BLL mediante los novedosos DataSources.
2º Llamar tantas veces como haga falta a la DAL desde la BLL haciendo múltiples comprobaciones.
3º Que la DAL se comunique con la BBDD mediante los procedimientos almacenados. Los procedimientos almacenados son sentencias SQL (T-SQL) que le damos a la base de datos para que se vaya haciendo a la idea de que se las vamos a pedir, con lo que se mejora muchísimo en velocidad. Si alguien sabe del tema se estara riendo de la definición, pero así no entendemos.
4º Yo he hecho funciones que se heredan de una clase madre para ser ejecutadas desde la DAL, sobre todo de las que no requieren respuesta (insert, update y delete), y algo de las que sí requieren (selects). De este modo, el código disminuye en 5:1

SIEMPRE:
- Se usan clase tipadas para todo, por lo que, por ejemplo, de un post de un foro no se lee desde un datareader como se viene haciendo siempre: dr["TitulodelPost"].ToString(), sino de una forma tipada: post.Titulo. Entre otras cosas, a parte de tener un código más claro y sencillo, nos aprovechamos de la intellisense del VisualStudio, por lo que escribir las pocas líneas que tenemos que escribir es muy rápido.
- Se usa la orden using para las partes más críticas del código. La orden using (que creo que sólo existen en C#, no en VB.NET) hace un try - catch y luego un finally liberando las variables mediante un .dispose(). Useasé, en lugar de:
try
{
sqlconnection con = new sqlconnection("string de conexion");
sqlcommand comm = new sqlcommand("nombredelprocedimientoalmacenaco", con);
con.open()
sqldatareader dr = comm.ExecuteReader();
while (dr.read())
{
//ejecutar operaciones
}
}
catch (Exception e)
{
//tratar la excepcion
}
finally
{
dr.close()
con.close();
dr.dispose();
comm.dispose();
con.dispose();
}


Vale con hacer:

using( sqlconnection con = new sqlconnection("string de conexion"), sqlcommand comm = new sqlcommand("nombredelprocedimientoalmacenaco", con), con.open(), sqldatareader dr = comm.ExecuteReader())
{
while(dr.read())
{
//Hacer cosas
}
}


Como veis se ahorra mucho espacio, y sobretodo no se te olvida cerrar nada, incluso se cierra si nos da error. Además, using lo hace todo de forma óptima, por lo que nos olvidamos del performance. Por cierto, el código no es del todo correcto, y se puede mejorar, pero lo he hecho rapidito.

El quid de la cuestión es que si hacemos este proceso una vez, nos va a servir no sólo para esta web sino para todas las que vengan en el resto de nuestras vidas, jeje, ya que siempre podemos mejorarlo.

Pero no nos desviemos del tema. Estábamos con que el martes y el jueves me pasé el día con TodoPub, así que el jueves por la tarde comencé a hacer el foro, me di cuenta de que faltaban algunas personalizaciones que sólo sirven para el foro, y creé la clase foro que heredaba de TodoPub, con las pirulillas que me hacían falta.
Hoy viernes he comenzado con la UI del foro (useasé, lo que ve el usuario) y lo he terminado.

El problema es que a final de tarde he decidido que voy a utilizar TodoPub también para las obras que la gente publique (ya os digo que en principio iba a hacerlo diferente, pero ha quedado tan bien que lo voy a reutilizar). La DAL y la tabla de la Base de datos van a ser las mismas, lo único es que he decidido almacenar el texto de la obra en un fichero XML, así será más rápido y no le daré tanta carga a la BBDD (los megas de la BBDD van caretes). Al hacerlo así he añadido un par de campos a la tabla de la base de datos (valoración y votos), por lo que ahora me da error y no funciona bien el foro, pero el lunes lo arreglo en unos minutos.

Mi gran duda ha sido si, para TodoPub, utilizar una tabla con muchos campos o dos tablas, una con campos importantes y otra con campos secundarios. Al final me he decidido por una sola tabla, ya que en el 90% de las veces me hace falta toda la info a la vez, así que paso de estar haciendo uniones de tablas cada dos por tres. Además, las variables de cache de ASP.NET me permiten hacer que no se entre en la BBDD siempre, sólo cuando sea necesario.

Para acabar con TodoPub y sobretodo con el tema del foro, sólo decir que lo bueno de tenerlo organizado en tres capas es que es muy fácilmente ampliable. De momento el foro es superbásico, con lo que tiene cualquier foro, pero en un futuro se pondrán muchas más pijadas, de las que ahora mismo se me ocurren dos (aunque hay muchas más):
- La típica de que el sistema analice si el usuario ha leído ya el mensaje y sus respuestas. Supongo que será algo así como hacer otra tabla con una correspondencia IdPost, FechadeLectura, Lector, y que luego la BLL analice si has leido todos los mensajes del post, incluso cuántos has leido y cuántos no.
- Otra funcionalidad (que yo no he visto demasiado) es la de permitir al escritor el adjuntar tantos adjuntos como le de la gana. Vamos, que no haya número máximo de adjuntos. Por ejemplo: ficheros excel, word, imágenes, archivos flash, links, y todo ello tanto externo como almacenado en el servidor. Se trata de que el usuario adjunte un fichero y que el sistema identifique de qué se trata.

Bueno, paro ya de escribir. Antes del 12/8 debe estar acabada la versión beta de letrasenlared... tendré que echarle un par de wevos la semana que viene!!!

Comentarios: Publicar un comentario

<< Home

This page is powered by Blogger. Isn't yours?