Documente Academic
Documente Profesional
Documente Cultură
Gestor de Noticias
‘Alligator’
Es responsabilidad del usuario el cumplimiento de todas las leyes de derechos de autor aplicables. Ningún
elemento de este contenido (documentos, elementos gráficos, vídeos, transparencias y otros recursos
didácticos asociados), ni parte de este contenido puede ser reproducida, almacenada o introducida en un
sistema de recuperación, ni transmitida de ninguna forma ni por ningún medio (ya sea electrónico, mecánico,
por fotocopia, grabación o de otra manera), ni con ningún propósito, sin la previa autorización por escrito de
Fomento Ocupacional FOC SL.
Este contenido está protegido por la ley de propiedad intelectual e industrial. Pertenecen a Fomento
Ocupacional FOC SL los derechos de autor y los demás derechos de propiedad intelectual e industrial sobre
este contenido.
Sin perjuicio de los casos en que la ley aplicable prohíbe la exclusión de la responsabilidad por daños,
Fomento Ocupacional FOC SL no se responsabiliza en ningún caso de daños indirectos, sean cuales fueren
su naturaleza u origen, que se deriven o de otro modo estén relacionados con el uso de este contenido.
1.1 Introducción:
El proyecto de gestión de noticias consiste principalmente en un núcleo de librerías
destinadas a desarrollar las funciones más comunes de un periódico digital típico. En
torno a estas librerías se disponen una aplicación de escritorio a través de la que
podemos gestionar las entradas, maquetar los contenidos, previsualizarlos y en
definitiva estructurar la página. Finalmente una aplicación Web Windows Forms se
encarga, sobre la información recogida de la base de datos y que ha sido
manipulada y estructurada por las librerías, de servirla al usuario final en forma de
una página web dinámica.
1.2 Justificación
Para la elección del proyecto, mas allá de cuestiones como la originalidad, u otras
consideraciones secundarias, he primado las cuestiones prácticas que consoliden los
conocimientos del módulo, por lo que he tenido en cuenta mayormente que englobe
las principales materias impartidas en el curso; Implementación de librerías,
orientación a objetos, aplicaciones de escritorio, consultas, manejo de bases de
datos y programación Web. Finalmente pretendo incluir al menos un lenguaje no
usado en el curso como complemento adicional. Un módulo en JavaScript.
-Adaptación de un gestor de código libre: Existen varios gestores de gran difusi ón,
algunos especializados en el ámbito de los periódicos online como por ejemplo
OpenCms. Esta alternativa nos obliga primero a documentarnos y conocer bien la
lógica del programa antes de intentar adaptarlo a nuestras necesidades. La
desventaja de esta alternativa es que si bien el proceso de rediseño puede ser
bastante ágil, ya que disponemos de toda la funcionalidad de forma prexistente, no
podemos en principio estimar el tiempo que necesitaremos dedicar a el conocimiento
de la aplicación, ni el nivel de complejidad que nos vamos a encontrar. En contra,
una vez familiarizados con ella podremos aplicar la solución a una gran variedad de
proyectos con unos plazos de entrega muy ajustados.
2. Objetivos Marcados
El proyecto debe alcanzar los siguientes objetivos:
C# para las librerías, HTML y CSS para las plantillas, SQL para las consultas a
BBDD, Asp.Net para el código web, JavaScript y la interface DOM para un Slider.
Nota: En principio la elección más lógica del gestor de BBDD debiera ser SQL Server
que es el sistema que hemos tratado en el curso. Sin embargo, y teniendo en cuenta
el plazo de entrega, a la hora de desplegar la solución y buscar un servidor gratuito
la necesidad de hacerlo sobre este último puede complicarse debido a las
restricciones y política del hosting. En este sentido la utilización se Access, como un
simple archivo que centraliza los datos y que se ubica en una simple carpeta de la
solución es una elección que facilita mucho este proceso. Sin embargo en caso de
que la aplicación requiriese una alta concurrencia esta decisión seria inadecuada, se
toma solo por tratarse de un ejercicio.
Esta ventaja no esta disponible en caso de que la pagina este destinada a alojarse
en un servidor propio y este deba ser adquirido junto a la aplicación.
Resulta bastante complejo conocer la arquitectura hardware necesaria que requerirá
un software en proyecto, sin realizar ningún tipo de prueba de rendimiento, incluso si
establecemos un numero aproximado de visitas por día.
En el módulo de sistemas realizamos un trabajo sobre el montaje y el presupuesto
de un equipo servidor de prueba. Está dentro del segmento básico, y podría utilizarse
como punto de partida.
Contenido:
-Modelado UML
-Clases: Interfaces y breve definición.
-Modelo Relacional
-Esquema de la Base de datos.
-Recursos Hardware y software
-Planificación temporal.
void BeginTransaction(System.Data.IsolationLevel Isolation);
void Close();
void CommitTransaction();
OleDbConnection Connection { get; }
ErrorStore Errors { get; }
void Open();
void RollBackTransaction();
OleDbTransaction Transaction { get; }
[SECCION]
Clave1:valor1
Clave2:valor2
PostTemplateProvider GetTemplateProvider(int
IdModule, int Style, int ProvProfilefk,
PageTemplateProvider PageProvider, int LinkedTo);
PostTemplateProvider
Provider_IdentificationMarker(string IdPosition,
string StylePosition);
PostTemplateProvider
Provider_TypicalCommentsRelateds(string
MaxPostRelated, int IdModule, int Style,
PageTemplateProvider PageProvider, int LinkedTo);
bool BuildDynamicCachePost(PostTemplateProvider
DataProvider);
string Code { get; }
string CodeTemplate { get; }
string Css { get; }
FileCache CssFileCache { get; }
void DeleteCacheExpired();
bool GetCachedPosts(int IdItem, int IdLink, DateTime
DateItem, out string ValueItem);
string Html { get; }
string Identificator { set; }
ErrorStore MErrors { get; }
string Name { get; }
void SetCachedPosts(int IdItem, int IdLink, string Code,
DateTime DateItem);
bool BuildTemplateCollection();
void ClearCacheResult();
ErrorStore Errors { get; }
PostTemplate Get(string NameModule);
SortedList<string, LibraryGestorNews.PostTemplate>
GetCollection { get; }
CssPathCollection GetPathCollections { get; }
(url?parameter1=valor¶meter2=valor2)
string ErrorMessages();
bool SetWeb(string Url, string HtmlCode, string CssCode);
bool TryGetWeb(int Url, out string HtmlCode, out string
CssCode);
AUTHOR
Columnas
CATEGORY
Columnas
COMMENTS
Columnas
FAMILYPROVIDERS
Columnas
FONTSIZES
Columnas
METADATA
Columnas
METADATACATEGORY
Columnas
METADATADYNAMIC
Columnas
NEWS
Columnas
NEWSCONTAINERS
Columnas
NEWSCONTAINERSTRANS
Columnas
IdContainerTrans Entero largo 4
IdSty leContainerfk Entero largo 4
IdContainerfk Entero largo 4
IdProv iderProfilefk Entero largo 4
Title Texto 255
SubTitle Texto 255
ImageHead Texto 255
ImageFoot Texto 255
NEWSTRANS
Columnas
ORPHANS
Columnas
PROVIDERS
Columnas
PROVPROFILES
Columnas
SECTIONPOST
Columnas
STYLE
Columnas
STYLEPOSITION
Columnas
TAG
Columnas
TYPEMODULES
Columnas
WEBCACHE
Columnas
CssCode Memo
Recursos software
Se usarán las siguientes herramientas software:
C# para las librerías, HTML y CSS para las plantillas, SQL para las consultas a
BBDD, Asp.Net para el código web, JavaScript y la interface DOM para un Slider.
Nota: En principio la elección más lógica del gestor de BBDD debiera ser SQL Server
que es el sistema que hemos tratado en el curso. Sin embargo, y teniendo en cuenta
el plazo de entrega, a la hora de desplegar la solución y buscar un servidor gratuito
la necesidad de hacerlo sobre este último puede complicarse debido a las
restricciones y política del hosting. En este sentido la utilización se Access, como un
simple archivo que centraliza los datos y que se ubica en una simple carpeta de la
solución es una elección que facilita mucho este proceso. Sin embargo en caso de
que la aplicación requiriese una alta concurrencia esta decisión seria inadecuada, se
toma solo por tratarse de un ejercicio.
Recursos Hardware
Estimar las especificaciones hardware para una aplicación online esta siempre
principalmente vinculado tanto al número de visitas concurrentes que tendrá el sitio,
como al tiempo de procesamiento que necesitamos para responder a esas visitas.
Esta cuestión será siempre el núcleo del que derivaremos nuestras características
hardware.
Esta ventaja no esta disponible en caso de que la pagina este destinada a alojarse
en un servidor propio y este deba ser adquirido junto a la aplicación.
Periodo Tarea
20-10-2012 / 10-11-2012 Implementación de la librería y el modulo javascript
11-11-2012 / 16-11-2012 Desarrollo de una app de escritorio básica para gestión de la BD
17-11-2012/ 18-11-2012 Pruebas en Hosting
5.-Pruebas e Implantación
5.1-Pruebas realizadas en el proyecto
Las pruebas sobre el proyecto se dividen en dos fases. La primera sobre el Gestor de contenidos y la
siguiente sobre el proyecto de pagina w eb.
Sobre el gestor de contenidos he realizado las correspondientes clases de equivalencia y casos de prueba
sobre los datos que acepta la interface.
CLASES DE PRUEBA
Sobre la pagina w eb he realizado unas pruebas de carga utilizando la aplicación gratuita Jmeter. Se establecen 3
escenarios sobre los que se han realizados las pruebas y sobre los que se muestran los resultados. Uno Optimo en
el que el servidor aun dispondría de cierto margen de seguridad para admitir algo mas de sobrecarga. Uno Limite
en el que el servidor se encuentra absolutamente saturado. Y uno Extremo en el que se ha desbordado
la capacidad del servidor. A través de estos escenarios podemos establecer el numero de solicitudes máximas que
se pueden gestionar por minuto. Las pruebas se han realizado tanto en local como en el hosting de la pagina,
sin embargo para comprobar exclusivamente las características y rendimiento de la aplicación eliminando los
factores derivados de los tiempos de resolución de dns, el redireccionamiento de dominio gratuito
contratado, y las limitaciones de respuesta del hosting también gratuito, se incluyen solo las pruebas con IIS en
local. Estas pruebas miden por tanto el tiempo que trata la aplicación en gestionar las solicitudes sin ningún tipo
de interferencia y se considera el tiempo de respuesta mínimo que la aplicación puede responder a las
solicitudes. Esta rendimiento esta determinado por el equipo en el que se realizan las pruebas. Un modesto
ordenador Dual de 1800 Mhz con 3
Gb de Ram. La ejecución de estos test sobre un verdadero servidor de pago debería arrojar resultados muchísimo
mejores.
ESCENARIO OPTIMO:
1000 USUARIOS SOLICITANDO CONEXION EN UN PERIODO DE 400 SEGUNDOS (1 SOLCITUDx0.4 sds)
En esta prueba se observa un rendimiento constante de solicitudes. Los picos finales corresponden a una
advertencia de antivirus y muestra lo dependiente que son los resultados a el entorno de ejecución. En este test no
se ha inicializado la aplicación en la primera solicitud. En esta primera solicitud no puede gestionarse el cacheado
de Modulo implementado en la aplicación y por lo tanto los resultados de la solicitud son muy altos en la solicitud 1.
En el gráfico vemos la caída de rendimiento inicial por la primera solicitud, muy acusada, junto con el inicio de los
test de prueba, la linea azul se corresponde con la recuperación del ritmo de respuestas. El mapa de puntos negros
indica el tiempo real de respuesta y la linea violeta el promedio. Vemos que permanece estable durante
la ejecución de toda la prueba excepto la primera variación inicial.
Un resumen de la prueba de estrés, las solicitudes varían entre 381 ms y 9091. Con un promedio de de 507. Unas
dos paginas por segundo.
En este caso si se ha realizado una primera solicitud previa de pagina para descongestionar la aplicación y tener
disponible el cacheado de pagina. Los resultados son muy parecidos, existe una acumulación inicial de solicitudes,
este lo achaco a la caída de rendimiento del servidor que coincide con el inicio del test.
Aquí se demuestra como la primera solicitud tan solo consume 544 ms, demostrando que la aplicación
esta cacheando. Los tiempo sin cache están entre los 3 segundos.
El sumario del test. Aunque el promedio por pagina es menor se ha respondido a las mil solicitudes con
mas prontitud. Vemos el rendimiento incrementado en 2,8 respuestas por segundo frente a las 2,4 anteriores.
Vemos como la gráfica tiene una orientación invertida. Los usuarios solicitan pagina con mas rapidez de lo que el
servidor es capaz de gestionar las solicitudes. Los tiempos se acumulan y se producen retrasos significativos.
Al final de la prueba, en las ultimas solicitudes se pueden observar retrasos de hasta 88 segundos frente a los 500
ms de la prueba Optima que se muestra a continuación. Como se ve la ultima solicitud en la prueba optima son de
466 ms. Se produce un retraso de 88000 ms en una pequeña variación en el incremento de carga. Esto se debe a
que una vez superado el umbral de respuesta del servidor los resultados son acumulativos.
Aquí se aprecia como el promedio y los tiempos de respuesta tienen linea ascendente. Desconozco porque se
produce una mayor dispersión de los tiempos de respuesta a medida que las solicitudes en cola van
aumentando. Puede que tenga algo que ver con la memoria ram, pero no soy capaz de interpretar porque
los puntos son tan consistentes (tiempos de respuesta casi idénticos) al principio de la gráfica y se van
difuminando al final.
gratuito. Ww w.tecnocompile.net.ms -
Es una versión completa de la w eb con algunas actualizaciones de noticias, comentarios, y funcionalidad de las
categorías.
Notas:
1)El host ha expirado intentare volverlo a poner disponible en los próximos días.
2)Inesperadamente Firefox ha dejado de mostrar los estilos utilizar preferentemente chrome o IE
[NOMBRE DEL ALUMNO] [CICLO] PÁGINA 33]]
FOMENTO OCUPACIONAL FOC ®
2) Pulse en Siguiente
3) Elija si quiere que el programa este disponible para el usuario actual o para todos lo
usuarios y pulse en examinar para seleccionar la carpeta de instalación.
2) El proyecto trabaja directamente sobre una ruta r elativa por lo que no tendrá que
especificarla, el programa la detectara y la almacenara en memoria. Sin embargo si tendrá
que realizar un cambio en el fichero config.gnc.
[SERVER]
Domain: http://heechee-001-site1.smarterasp.net/
NewParameter1:IdNew
NewDetailPage:Detail.aspx
5) Tener en cuenta que la primera solicitud puede demorarse algo d e tiempo ya que realiza
los procesos de inicialización y almacenamiento. A partir de la segunda y hasta que
transcurra un tiempo desde el cierre de la ultima sesión las subsiguientes peticiones serán
muchos mas rápidas ya que recogerán los resultados del cacheado de modulo.
7) Este guía no pretende ser una enumeración exhaustiva de los pasos necesarios para
poner a punto la página web. Dependiendo del hosting contratado deberán seguirse una
serie de pasos adicionales y formalidades, tales como establecer los niveles de seguridad,
la apertura de FTP, establecer los ficheros como lectura, escritura, públicos o privados,
disponer del componente MDAC para base de datos Access o instalarlo etc. También
ciertos servidores obligan a tener los archivos en ciertas ubicaciones especiales como las
bases de datos. Estos pasos deberán consultarse con el apoyo técnico del hosting en
cuestión.
Introducción:
Alligator Manager es una aplicación que nos permite gestionar visualmente la base de
datos que utiliza la aplicación web.
A continuación se irán mostrando las ventanas principales, sus secciones y significado
de cada una, y datos sobre su modo de utilización, así como conceptos necesarios para
entender la lógica de la aplicación.
En la ventana principal que nos aparece al iniciar la aplicación se nos ofrece la posibilidad de
elegir entre la gestión de noticias o el apartado de maquetación. Ambas opciones están en la
parte superior y serán accesibles durante toda la vida de la aplicación.
Secciones:
(1) : Barra de edición de noticias. Nos permite añadir, editar, eliminar y guardar los
distintos registros de noticias.
(2) : Pestañas de navegación: Nos permite pasar a distintos aspecto de las noticias. En
body nos muestra el cuerpo de la noticia. Transformaciones nos muestra los
distintos estilos asignados a la noticia, se comentara más adelante.
(3) : Grid con las Noticias almacenadas en la base de Datos.
ImageAvatar: Ciertas noticias, como el listado de las más leídas, pueden necesitar
una representación pequeña de las mismas. Este campo nos permite direccionar
esta imagen a través de una ruta http.
LinkFullNew: El enlace que lleva a la noticia. Es requerido pero el sistema lo
ignorara si se establece la Url Automática.
AuthorPhoto: El nombre del autor de la fotografía si existe y la noticia requiere
fotografía.
IdTagFk: Se trata de un identificador de palabra clave. Se introduce a través del
desplegable explicado mas adelante.
DateNew: La Fecha en que se inserto o modifico por última vez la noticia.
Visitors: El numero de visitas que ha recibido la noticia. No se puede modificar
manualmente. Actualmente la aplicación no dispone de funcionalidad para detectar y
contabilizar las visitas, solo para tenerlas en cuenta a la hora de mostrar resultados.
Publish: Nos permite mantener una noticia en modo de edición, o sin completa r y
que el sistema no la tenga en cuenta a la hora de publicarla. Una vez activado a true
la noticia pasara a formar parte de los resultados de la página web.
(4) Controles para la edición de los campos: El modo de UrlAutomatica nos permite que
la propia página web establezca una dirección de redireccionamiento automático
basado en el identificador de noticias. En caso de no querer utilizarlo, como por
ejemplo enlazar a un recurso externo, utilizara el campo Enlace si se establece
como no automático.
(5) Previsualizacion de la noticia: Elige uno de los estilos de que dispone la noticia y lo
muestra. Nos sirve para identificar la noticia ya que su identificador numérico no nos
proporciona ninguna información.
(6) Controles de Zoom del visualizador: Controla el Zoom del visualizador y nos permite
adaptar el tamaño a las dimensiones de la noticia que estemos viendo.
Concepto de transformación:
Secciones de la interface:
Introducción:
Definición de la Interface:
Introducción:
Nota: El campo No Repetir esta definido por defecto a true, indica que si una noticia esta
asignada a un contenedor, no se debe duplicar fuera de este en las consultas dinámicas. Por
ejemplo en las categorías.
Dado que durante la confección de este documente se han introducido varios aspectos a
incluir aquí, me centrare en aquellos que aun no han sido desarrollados.
La aplicación web utiliza para cada uno de los módulos dos ficheros que establecen la
estructura y estilo de las mismas. Uno de ellos tendrá extensión .htf y se encontraran la
carpeta HtmlTemplates y otra con extensión .css en la carpeta CssTemplates. De los
dos ficheros el primero será la plantilla que determina la estructur a del módulo y los
campos a resolver y la segunda toda la información referida a los estilos de hoja en
cascada.
Una plantilla no es mas que un fragmento de código HTML que incluye ciertos
metadatos que hacen referencia a como deben resolverse ciertas porciones del código,
en que campo están basados y ciertos parámetros que determinan la forma adecuada
de resolverse. Para este propósito la aplicación utiliza una serie de tokens o etiquetas y
ciertos parámetros de resolución. Los identifico a continuación a ntes de poner un
ejemplo.
Antes de ello hablare sobre los datos que recopilan todas las plantillas.
Independientemente del proveedor de datos al que una plantilla este asociado, cada
plantilla esta relacionada necesariamente con dos estructuras de datos.
Etiquetas de resolución:
[+…+]: Iteradores: Los iteradores indican que todos los reemplazadores anidados
dentro de ellos y que tengan el parámetro Linked==True (explicado mas adelante) deberán
resolverse una vez por cada registro que exista en el conjunto de resultados múltiple. Para
verlo con un ejemplo:
Visitar:
[+
[!Relacionados!,,Linked==True]
+]
En cierto sentido el iterador funciona como un bucle for each, pero dado que uno de los
requisitos a la hora de iniciar el proyecto fue que estuviera orientado al diseñador, sin
conocimientos previos de programación, no es necesario introducir ningún tipo de código para
realizar tal proceso, con tan solo introducir este token el recorrido for…each se realiza
transparentemente por la aplicación. Los Iteradores pueden modificarse en el a rchivo de
configuración en las claves IteratorTokInit:[+ y IteratorTokend:+]
Token de Sección pendiente de resolución: |% : Este token no tiene un modelo de inicio y fin
es igual para ambos. Su significado es que si cualquiera de los campos con el atribut o
necessary==True (mas adelante) no puede resolverse (resultado null o “”) toda la sección se
omite completamente en la salida del código HTML. Lo explicare en un ejemplo.
En los módulos de noticias es típico que algunas de ellas dispongan de una fotograf ía y otras
no. Para evitar que sea necesario crear una plantilla para cada versión se puede utilizar una
codificación como la que sigue que servirá en ambos escenarios:
SectionTok:|%
,, - == : Los Tokens delimitadores entre parámetros son dos comas (,,) y el de igualdad es el de
dos símbolos de igual (==). Se modifica en el archivo de configuración en las keys
ParameterTokDelimiter:,, y ParameterTokEqual:==
"[!ImageSrc,,Necessary==True!]"
A continuación se describen los parámetros que pueden asociarse con cualquier etiqueta de
resolución.
Resultado:
3) Plantillas de Pagina:
Para la organización de los módulos dentro de la estructura de la página se utilizan las
plantillas de página. Constan de un identificador de posición y uno de anchura. De la
construcción de esta plantilla depende la estructura general de la página y la ub icación
de todos los módulos. Las plantillas de pagina al igual que las de modulo tienen
asignada un fichero de código css. Su carpeta es PageHtmlTemplates y
PageCssTemplates. A continuación añado la estructura de simplest.pft que es la
página principal o Main.aspx.
<div class="container">
[!7:1000!] ;Posición de Encabezado (Tecnocompile)
<div class="header">
<div class="cabeceraleft"> ;A dos columnas
[!8:570!] ;Posición Noticia Izquierda
</div>
<div class="cabeceraright">
[!9:400!] ;Posición de 2 noticias a la derecha
[!10:400!]
</div>
<!-- end .header --></div>
<div class="sidebar1"> ;A tres columnas
[!11:390!] ;Noticias de la columna izquierda
[!12:390!]
[NOMBRE DEL ALUMNO] [CICLO] PÁGINA 50]]
FOMENTO OCUPACIONAL FOC ®
[!13:390!]
[!14:390!]
[!15:390!]
[!16:390!]
[!17:390!]
[!18:390!]
[!19:390!]
[!20:390!]
[!21:390!]
<!-- end .sidebar1 --></div>
<div class="content">
[!22:230!] ;Noticias de la columna Central
[!23:230!]
[!24:230!]
[!25:230!]
[!26:230!]
[!27:230!]
[!28:230!]
[!29:230!]
[!30:230!]
[!31:230!]
<!-- end .content --></div>
<div class="sidebar2">
[!32:340!] ;Noticias de la columna Derecha
[!33:340!]
[!34:340!]
[!35:340!]
[!36:340!]
[!37:340!]
[!38:340!]
[!39:340!]
[!40:340!]
[!41:340!]
<!-- end .sidebar2 --></div>
<div class="footer">
<div class="footervideos"> ;A 1 columna
[!42:1000!] ;Modulo de videos
</div>
[!43:1000!] ;Pie de Pagina
<!-- end .footer --></div>
<!-- end .container --></div>
Tanto las plantillas de modulo como de pagina a la hora de resolver los campos utilizan
un sistema de indexación. Cada campo a resolver o posición de pagina tiene asociado
un valor numérico que se utiliza a la hora de insertar el campo o el modulo. Esto ha ce
que el tiempo de resolución sea mucho mas rápido que un simple método replace que
recorra todo el documento una y otra vez de principio a fin.
Muestro a continuación una grafica acerca del cumplimiento de los 10 puntos que se
establecieron como objetivos del proyecto.
Hay tres tareas en las que no se ha conseguido un 100 % de cumplimiento a mi juicio las
causas son las siguientes:
Feedback: Con Feedback me refiero a las respuestas en forma de comentarios que el usuario
puede enviar sobre las noticias. Se ha tenido en cuenta estos comentarios al mostrar cada
detalle apareciendo al pie. Pero no se ha introducido la interface pa ra que el usuario pueda
escribirlos desde la interface. Considero pues que la tarea esta a un 50%
1)
La principal es que con Access modifico las tablas en local y rescribo la bd en el
servidor para las actualizaciones. Este sistema además de incomodo es
impracticable por los tiempos de subida a medida que la base de datos vaya
alcanzando mayor peso. Hay que implementar un servicio de conexión remoto a un
sistema de gestión de base de datos como SQL Server en el servidor y centralizar
ahí todos los cambios.
2)
Los accesos a Access son muy lentos, en parte porque Access en las aperturas
de conexiones crea un fichero ldb que hace que rendimiento baje. Se han l imitado
estas aperturas al mínimo pero SQL Server mejoraría este aspecto, así como las
velocidades en las consultas y transacciones.
3)
Por ultimo se han encontrado algunas limitaciones en la sintaxis de Access que
han sido solucionadas parcialmente con cierta dificultad. Una de ellas es la función
RowCount inexistente en Access, otra es la imposibilidad de crear desencadenadores,
que me hubieran sido muy útiles en las operaciones de mantenimiento.
4) Módulos adicionales: Habría que crear una nueva categoría de módulos que
pudiesen incorporar asp.net para ciertas operaciones más complejas que requieren
necesariamente codificación. Un ejemplo serian las típicas encuestas de las páginas
de noticias.
6.5 Bibliografía:
Todo el proyecto ha sido realizado consultando o bien el temario del curso o bien algunas
paginas web y un libro de JavaScript que pongo a continuación.