Buenas practicas para el desarrollo de aplicaciones ASP.NET & Oracle

© 2008 Telmex S.A.
Buenas practicas de desarrollo
Gerencia de Analisis y Desarrollo de Sistemas

All rights reserved. No parts of this work may be reproduced in any form or by any means - graphic, electronic, or
mechanical, including photocopying, recording, taping, or information storage and retrieval systems - without the
written permission of the publisher.
Products that are referred to in this document may be either trademarks and/or registered trademarks of the
respective owners. The publisher and the author make no claim to these trademarks.
While every precaution has been taken in the preparation of this document, the publisher and the author assume no
responsibility for errors or omissions, or for damages resulting from the use of information contained in this
document or from the use of programs and source code that may accompany it. In no event shall the publisher and
the author be liable for any loss of profit or any other commercial damage caused or alleged to have been caused
directly or indirectly by this document.
Printed: octubre 2008 in (whereever you are located)
Buenas practicas de desarrollo
© 2008 Telmex S.A.

Buenas practicas de desarrollo4
© 2008 Telmex S.A.
Lista de contenidos
Foreword 6
Apéndice A - Introducción 8
................................................................................................................................... 81 Propósito
................................................................................................................................... 82 Documentos relacionados
................................................................................................................................... 83 Historia de Revisiones
Apéndice B - Estandarización C# 10
................................................................................................................................... 101 Nomenclatura
..........................................................................................................................................................10Estilos de Capitalización
..........................................................................................................................................................10Nombres de Entidad
..........................................................................................................................................................11NameSpace
..........................................................................................................................................................11Componentes
..........................................................................................................................................................11Capas de la Aplicación
..........................................................................................................................................................12Abreviaturas de Tipos
..........................................................................................................................................................12Archivos y Proyectos
..........................................................................................................................................................13Clases & Interfaces
..........................................................................................................................................................13Propiedades de Clases
..........................................................................................................................................................14Metodos
..........................................................................................................................................................14Variables
..........................................................................................................................................................14Constantes
................................................................................................................................... 142 Estetica del Codigo
..........................................................................................................................................................15Code Behind
..........................................................................................................................................................15Regiones
..........................................................................................................................................................16Variables
Apéndice C - Estandarización Web 18
................................................................................................................................... 181 Proyecto Web
..........................................................................................................................................................18Regionalización de Paginas
..........................................................................................................................................................18Exportación de Excel
..........................................................................................................................................................18Titulo de Páginas
Apéndice D - Estandarización JavaScript 21
................................................................................................................................... 211 Reglas Generales
..........................................................................................................................................................21Acceso a objetos
..........................................................................................................................................................21Acceso al valor de un objeto
..........................................................................................................................................................21Style
..........................................................................................................................................................22innerHTML
..........................................................................................................................................................22Templates
Apéndice E - Estandarización CSS 25
................................................................................................................................... 251 Organización de los archivos
................................................................................................................................... 252 Arquitectura
..........................................................................................................................................................25Orden de escritura
..........................................................................................................................................................26Comentarios

5Contents
5
© 2008 Telmex S.A.
..........................................................................................................................................................26Tabs o Espacios.
..........................................................................................................................................................26Nombres de etiquetas, identificadores y clases.
Apéndice F - Sugerencias de seguridad 28
................................................................................................................................... 281 Servidor
................................................................................................................................... 282 SQL Server
................................................................................................................................... 283 IIS
................................................................................................................................... 284 Administracion de la seguridad
Apéndice G - Sugerencias de Oracle 30
................................................................................................................................... 301 Diseño de aplicaciones y modelo de datos
..........................................................................................................................................................30Tablas
.........................................................................................................................................................30Uso de Oracle Features
.........................................................................................................................................................33Equilibrar la flexibilidad y la performance
..........................................................................................................................................................33Indices
..........................................................................................................................................................34Vistas
..........................................................................................................................................................34Escritura de SQL
..........................................................................................................................................................35Practicas peligrosas
.........................................................................................................................................................35JoinMultiplesTablas

© 2008 Telmex S.A.
1 Introducción
Se desarrolla la guía de estilo para el desarrollo en C# de aplicaciones dentro del ámbito de proyectos
del departamento IT de Sistemas de Telmex en entorno .NET de Microsoft.
Incluye normas de programación y recomendaciones para el buen desarrollo de aplicaciones.
1.1 Propósito
Establecer un marco general para el desarrollo y mantenimiento de software que facilite la mantención,
escalabilidad, y la incorporación de recursos con un tiempo mínimo de inducción. Como también
corregir malos hábitos en el proceso de diseño del mismo.
1.2 Documentos relacionados
§ Documento de Arquitectura de Aplicaciones .NET
§ Documento de Componentes de Telmex para Aplicaciones .Net
1.3 Historia de Revisiones
Fecha Versión Descripción Autor
22/09/2008 1.0 Creación del Documento José Franco
13/10/2008 1.1 Modificación del Documento José Franco

© 2008 Telmex S.A.
2 Estandarización C#
2.1 Nomenclatura
Se describen los criterios generales relacionados con la forma de nombrar las distintas entidades
usadas en C#.
2.1.1 Estilos de Capitalización
Hay tres posibles criterios, que se utilizarán para facilitar la distinción entre variables, clases,
constantes, etc. Las opciones son:
§ Tipo “Pascal”: La primera letra de cada palabra que compone el identificador se pone en
mayúsculas. Es el tipo que se utiliza en la mayor parte de los casos (nombres de clases, de
métodos, de espacios de nombres, eventos, etc.). Por ejemplo: UsuarioRegistrado.
§ Tipo “Camel”: Igual que el anterior pero la primera letra es en minúscula. Se utiliza para
nombres de variables locales y parámetros de métodos. Por ejemplo: nombreCompleto.
§ Mayúsculas: Todo el identificador se pone en mayúsculas. Solo se usa para constantes o
macros definidas en el precompilador. Por ejemplo: DEBUG.
2.1.2 Nombres de Entidad
Para la elección de los nombres de las entidades que forman parte del desarrollo (ficheros fuentes,
librerías, procedimientos, variables, parámetros, proyectos, assemblies, etc.) se seguirán las siguientes
pautas generales:
§ Los nombres deben ser palabras, mnemotécnicos o combinaciones de ambas relacionados con
los nombres de las entidades del mundo real y con su función dentro del modelo lógico de la
aplicación. No harán referencia a la forma de implementarse en el código. Ejemplos:
ValorRetornado // Mal
CadenaConElNombre // Mal
NombreCompleto // Bien
§ Se formarán por la concatenación de una o más palabras sin usar separadores, espacios ni el
carácter “_”.
§ Pueden contener letras de la a A la Z, dígitos del 0 al 9. El primer carácter a de ser una letra,
aunque el carácter “_” podrá usarse como primer carácter pero solo para variables privadas que
se corresponden con una propiedad pública con igual nombre.
§ No obstante lo anterior, el carácter “_” podrá usarse cuando facilite la lectura del código.
class Persona
{
private int _edad;
public int Edad
{
get
{

Estandarización C#
© 2008 Telmex S.A.
11
return _edad;
}
set
{
if (value >= 0) _edad = value;
}
}
}
§ El uso de mayúsculas y minúsculas debe seguir unas normas que se comentará en cada caso.
§ Elija palabras que no creen ambigüedades. Tenga en cuenta que una palabra puede tener varios
significados y un significado puede expresarse con varias palabras.
§ Elija identificadores intentando ser claro, no ameno ni gracioso.
§ Nunca piense de un identificador que “por el contexto se deduce para que sirve”; elija
identificadores suficientemente indicativos incluso fuera de contexto.
§ No hay una longitud máxima ni mínima para los identificadores, aunque el sentido común
pondrá unos límites (no más de 2 ó 3 palabras).
§ Utilice el mismo idioma para todos los identificadores.
§ Podrán hacerse excepciones a estas reglas con un motivo bien y que deberán documentarse
adecuadamente.
2.1.3 NameSpace
§ Los nombres se elegirán según las normas generales.
§ Se usará capitalización tipo Pascal.
§ El nombre del espacio de nombres se elegirá conforme a la especificacion del documento de
Arquitectura.
2.1.4 Componentes
Cada componente, sera incluido dentro del Core de Telmex, con el prefijo de Telmex.Core.
Ejemplo:
Telmex.Core.ExceptionManager
Telmex.Core.Facades
Telmex.Core.Security
Telmex.Core.ServicesLayer
Telmex.Core.UI.WebControls
Importante: Esto es responsabilidad del Arquitecto, y necesitan la previa aprobación antes de generar
un assembly con este NameSpace.
2.1.5 Capas de la Aplicación
Supongamos que tenemos la aplicación "Seguridad", cuyo prefijo de aplicación es SEG.
Capa NameSpace
Capa de la interfaces DAO Telmex.SEG.dal.DAO

© 2008 Telmex S.A.
Capa de Implementación de Sql Server Telmex.SEG.dal.ImplMSSql
Capa de Implementación de Oracle Telmex.SEG.dal.ImplOracle
Capa de Modelo de la aplicación Telmex.SEG.Model
Capa de Servicios Telmex.SEG.Services
Capa Controladora/Presenter de la aplicación Telmex.SEG.Web.Controller
Capa de helpers para la UI Telmex.SEG.Web.Helpers
Para entender la arquitectura de las aplicaciones, consulte el documento de referencia de la misma.
2.1.6 Abreviaturas de Tipos
Los lenguajes .NET son fuertemente tipados. Esto significa que todas las variables, locales al método o
a la clase o estructura, métodos, parámetros, etc. tienen un tipo definido.
Siguiendo las recomendaciones de Microsoft son eliminados los prefijos que indican el tipo de dato en .
NET.
Lo único que se conserva es la “I” como prefijo en nombres de interfaces.
2.1.7 Archivos y Proyectos
Para la nomenclatura de nombres de ficheros y de proyectos se seguirán estas normas:
§ Los nombres se elegirán según las normas generales descritas en el apartado 3.1.1.1.

Estandarización C#
© 2008 Telmex S.A.
13
§ Utilizar siempre la extensión estándar para indicar el tipo de fichero. Por ejemplo:
.cs Clase de objetos en C#
.csproj Proyecto VisualStudio basado en C#
.htm Páginas Web
.asmx webService
.asmx.cs Clase C# asociada a un webService
§ Cada clase o interfaz deberá estar contenida en un fichero del mismo nombre.
§ Se creará un fichero específico para contener las declaraciones globales que no pertenezcan a
ninguna clase. Por ejemplo, para las enumeraciones se creará un fichero llamado “Enums.cs”.
2.1.8 Clases & Interfaces
§ Los nombres deberán ser palabras o frases formadas por nombres y/o sintagmas nominales (se
evitarán verbos, artículos, etc.).
§ No llevarán prefijo de tipo, pero las clases que sean interface, por convenio, irán precedidas de
una “I” mayúscula.
§ Cuando la clase derive de otra, menciónela en el nombre (siempre y cuando eso tenga sentido).
Por ejemplo, la clase derivada de “Usuario” podría ser “UsuarioAutentificado”.
§ Ciertos tipos de clases tienen sufijos universalmente aceptados:
o Exception para excepciones. Ejemplo FatalException
o Collection para colecciones. Ejemplo ActorCollection
o Delegate para delegados.
o Attribute para atributos.
o Base. Clases abstractas que implementan cierta funcionalidad común a varias clases
concretas.
2.1.9 Propiedades de Clases
§ Si se trata de una propiedad pública de la clase que encapsula a una variable privada de la
clase, ambas deberán llamarse igual, anteponiendo el prefijo “_” a la variable privada. Ejemplo:
Private int _edad;
public int Edad
{
get
{
return _edad;

© 2008 Telmex S.A.
}
set
{
if (value >= 0) _edad = value;
}
}
2.1.10 Metodos
§ Habitualmente serán verbos, sintagmas verbales o combinaciones de ellos con nombres o
sintagmas nominales.
§ Los nombres para miembros públicos pueden depender del contexto, es decir de la clase a la
que pertenecen; no así los que tengan otra visibilidad. Por ejemplo: un método público Borrar de
la clase Usuario podría llamarse “BorrarUsuario” por claridad, mientras que uno privado bastaría
con llamarlo “Borrar”.
public abstract void CrearNuevo();
public abstract void ValidarNombre();
public abstract void Borrar();
2.1.11 Variables
§ Se usará capitalización tipo Camel.
§ Los identificadores de matrices y demás colecciones deberán estar en plural.
2.1.12 Constantes
§ Se usará el mismo criterio de capitalización que para las variables: Pascal para las constantes
públicas y Camel para las privadas. También puede usarse solo mayúsculas en cuyo caso se
podrá utilizar el carácter “_” para separar palabras.
double const pi = 3.14;
double const PI = 3.14;
int const DIAS_SEMANA = 7;
2.2 Estetica del Codigo

Estandarización C#
© 2008 Telmex S.A.
15
2.2.1 Code Behind
Se deben respetar las siguientes normas de estética:
§ Los ficheros no superarán las 1200 LOC (Líneas de Código).
§ Cada fichero contendrá la definición de una sola clase.
§ Todos los ficheros con clases pertenecientes al mismo “namespace” estarán en un mismo
proyecto y en un directorio diferente del de otros “namespaces”. La compilación generará un
assembly por cada “namespace”.
§ Utilice las extensiones estándar para los nombres de fichero (cs, asmx, etc.)
2.2.2 Regiones
Aquí entendemos por “bloque de código” un grupo de líneas de código que forman un bloque lógico: un
grupo de declaraciones relacionadas entre sí, un procedimiento, un bloque if/else, etc.
Las “regiones” son una facilidad que proporciona VS.NET para hacer una subdivisión virtual del fichero
fuente en varias zonas. Durante la edición el desarrollador puede ocultar una o varias de las regiones y
dejar visible solo aquella/s sobre la que esté trabajando.
Buenas prácticas en la estética de los bloques de código
§ Evitar que un bloques de código ocupe más de una página de texto impreso (unas 60 líneas). Si
se da el caso, seguramente es un síntoma de un mal diseño de código.
§ Se utilizaran “regiones” para mejorar la legibilidad del código (nunca para “ocultar” código). No
se deberá abusar de ellas pues producirían el efecto contrario.
§ Los caracteres de llaves ( { y } ) siempre aparecerán solos en la línea.
using System;
using System.Data;
using System.Security.Principal;
using System.Threading;
namespace Telmex.Util.General
{
public class InfoUsuario
{
#region Constructor
static public string InfoUsuario()
{
//…
}
#endregion
#region Declaraciones
static double PI = 3.14;
//…
#endregion
#region Métodos
//...

© 2008 Telmex S.A.
#endregion
}
}
2.2.3 Variables
Normas de estética en las declaraciones:
§ Se pondrá una sola declaración por línea.
§ Cada declaración llevará un comentario en la línea anterior indicando su uso. Si la variable es
pública, el comentario deberá seguir el formato XML que se describe más adelante.
§ Se agruparán según su uso lógico -si procede- se añadirá un comentario por cada bloque. Por
ejemplo: un grupo con las variables estáticas, otro con las referidas a un formulario, otro para
procedentes de una base de datos, etc.
§ Si es posible se inicializará la variable en la misma línea.
§ Las variables locales deben declararse del mismo bloque de código donde se la usa de manera
que su ámbito de existencia sea el menor posible. Por ejemplo:
for (int indiceDia = 1; indiceDia <= 7; indiceDia++)
totalPorDia[indiceDia] = 0;
§ Las propiedades y variables públicas usarán nomenclatura Pascal.
§ Las miembros privados de las clases usarán nomenclatura Camel.
§ Debe evitarse el uso de variables globales en beneficio de las locales. En todo caso, la
nomenclatura será la misma.

© 2008 Telmex S.A.
3 Estandarización Web
Se describe los conceptos generales a considerar a la hora de diseñar una solución Web.
3.1 Proyecto Web
3.1.1 Regionalización de Paginas
Se regionaliza todo lo que es mensaje de usuarios.
Se generarán una carpeta App_GlobalResources, con un archivo de recursos "es.resx". En el cual, se
encuentran nuestros mensajes de la UI (User Interface).
Y utilizando el componente Telmex.Core.UI.Helpers, nos provee un Helper (PageHelper) que nos
permite acceder al contenido de este archivo.
UcTelmexMensaje1.Mensaje("ALERTA", Telmex.Core.UI.Helpers.PageHelper.
GetResourceLiteral("UsuarioNoEncotrado"));
Importante: Para mayor información recurra al documento de Componentes.
3.1.2 Exportación de Excel
Para la exportación de datos a Excel, poseemos un Helper. En Telmex.Core.UI.Helpers, el único
requisito es enviar un DataTable para la generación del mismo.
grpSrv = (ContractorService)ServiceLocator.GetService("ContractorServ"); ;
string fileName = "AGI_" + DateTime.Today.Year + DateTime.Today.Month +
DateTime.Today.Day + ".xls";
DataTable dt = grpSrv.getContractorDs().Tables[0];
List<string> _list = new List<string>();
_list.Add("Password");
Telmex.Core.UI.Helpers.OutputHelper.FlushExcel(dt, _list, fileName);
Importante: Para mayor información recurra al documento de Componentes.
3.1.3 Titulo de Páginas
El Title de las paginas, se "customizará" a través de un Web.sitemap.

Estandarización Web
© 2008 Telmex S.A.
19
Por ejemplo, con el siguiente:
<?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
<siteMapNode url="default.aspx" title="Seguridad" description="">
<siteMapNode url="mainPage.aspx" title="Pagina Principal"
description="" />
<siteMapNode url="aplicacionesList.aspx" title="Administración de
Aplicaciones" description="" />
<siteMapNode url="aplicacionesUpdate.aspx" title="Administración de
Aplicaciones" description="" />
<siteMapNode url="gruposList.aspx" title="Administración de Grupos"
description="" />
<siteMapNode url="gruposUpdate.aspx" title="Administración de
Grupos" description="" />
<siteMapNode url="ldapAdmin.aspx" title="LDAP" description="" />
<siteMapNode url="login.aspx" title="Login" description="" />
<siteMapNode url="logout.aspx" title="Logout" description="" />
<siteMapNode url="usuariosList.aspx" title="Administración de
Usuario" description="" />
<siteMapNode url="usuariosPopUp.aspx" title="Usuarios" description
="" />
</siteMapNode>
</siteMap>
Y se generará una clase WebBase de System.Web.UI.Page, la cual en su evento de inicialización
setee el título recuperado del archivo a través del componente Telmex para interfaz de usuario. Esta
misma estará en el AppCode del Proyecto Web.
public class WebPage : System.Web.UI.Page
{
protected void Page_Init(object sender, EventArgs e)
{
Page.Title = Telmex.Core.UI.Helpers.
GetPageTitleBasedOnSiteNavigation();
}
}
Las Paginas del WebSite, en vez de heredar de System.Web.UI.Page lo harán de WebPage.
public partial class aplicacionesList : WebPage
{
protected void Page_Load(object sender, EventArgs e)
{
}
}

Estandarización JavaScript
© 2008 Telmex S.A.
21
4 Estandarización JavaScript
Para codificación en JavaScript, se implementará el uso de Prototype.
Ya que brinda soporte en los siguientes Browsers:
Browser Version(s)
Mozilla Firefox = 1.5
Microsoft Internet Explorer = 6.0
Apple Safari = 2.0
Opera = 9.25
4.1 Reglas Generales
Se describen los errores usuales, y la correcta codificación en Prototype.
4.1.1 Acceso a objetos
Se accederá a los objetos con el operador $.
Antes
<script type="text/javascript">
var myObject = document.getElementById('foo');
</script>
Ahora
var myObject = $('foo');
</script>
4.1.2 Acceso al valor de un objeto
Cuando se desee acceder al valor de un objeto, se usará el operador $F.
Antes
var woot = document.getElementById('bar').value;
var woot = $('bar').value;
</script>
Ahora
var myObject = $('foo');
</script>
4.1.3 Style
Para evitar problemas de compatibilidad entre distintos browser, ya no se accederá al style de los
objetos directamente.

© 2008 Telmex S.A.
Antes
$('footer').style.height = '100px';
$('footer').style.background = '#ffc';
</script>
Ahora
$('footer').setStyle(
{
height: '100px',
background: '#ffc'
}
);
</script>
4.1.4 innerHTML
Para modificar al contenido HTML de un objeto, ya no se accederá a través de innerHTTML, sino a
través del método update. Otra ventaja que provee esto, es en caso de concatenar contenidos.
Antes
$('element').innerHTML = 'text text text';
</script>
Ahora
$('element').update('text text text');
</script>
4.1.5 Templates
Para evitar HTML embebido en JavaScript, se implementa el uso de Templates.
Antes
$('productTable').innerHTML =
$('productTable').innerHTML
+ '<tr><td>' + productId + ' '
+ productName + '</td></tr><tr><td>'
+ ProductId + ' ' + productPrice
+ '</td></tr>';
</script>
Ahora
var rowTemplate = new Template('<tr><td>#{id} #{name}</td></
tr><tr><td>#{id} #{price}</td></tr>');
$('productTable').insert(

Estandarización JavaScript
© 2008 Telmex S.A.
23
rowTemplate.evaluate(
{
id: productId,
name: productName,
price: productPrice
}
)
);
</script>

Estandarización CSS
© 2008 Telmex S.A.
25
5 Estandarización CSS
Estos lineamientos o guía de creación de código CSS permiten llevar un trabajo ordenado y mejor
productividad tanto en proyectos personales como en equipos de trabajo. Sigue estas pequeñas reglas
para tener una mayor organización y lógica en tu proceso de diseño de hojas de estilo.
5.1 Organización de los archivos
Para mejorar los cambios de diseño y forma sin afectar otras áreas, dividimos en 5 partes básicas todos
nuestros estilos. Teniendo estos archivos:
· layout.css: Todo lo relacionado con posicionamiento, esquema del diseño, etc. Exclusivamente.
· color.css: Colores de fondo e imágenes. En el caso de los background también sus repeticiones.
Bordes de elementos, estilos de borde.
· fuentes.css: Tipo de fuente o tipografía, adornos de fuente (negrita, cursiva, subrayado). Ancho de
líneas, espaciado, tamaño de fuente.
· header.css: Todos los estilos del header/botonera del diseño.
· forms.css: Todos los estilos de formularios y elementos de interacción.
Además de estos, habrá un archivo que una a todos y sea el único que llamaremos en el HTML.
@import url("header.css");
@import url("color.css");
@import url("fuentes.css");
@import url("forms.css");
@import url("layout.css");
5.2 Arquitectura
5.2.1 Orden de escritura
Dentro de los archivos CSS podemos colocar estilos para etiquetas, para identificadores, para clases,
así como ciertos casos especiales. Colocaremos los estilos en este orden:
1. Etiquetas (Tags de HTML)
2. Identificadores
3. Clases
4. Casos especiales
A su vez, estos los organizaremos en orden alfabético. Ejemplo:
body {}
label{}
span{}
#bate{}

© 2008 Telmex S.A.
.armageddon {}
.flamas {}
.sangre {}
5.2.2 Comentarios
En caso de que haya estilos especiales o algún cambio importante dentro del equipo de desarrollo, se
colocarán comentarios al principio de esa etiqueta de la siguiente manera. Si el cambio no se quita o
modifica, se debe mantener el comentario:
/* Por Usuario 17 de Agosto del 2008
"Hack" para lograr x efecto.
*/
.inferior
{
clear: both;
}
5.2.3 Tabs o Espacios.
En el contenido dentro de corchetes, siempre se identará este contenido con tabs. Cualquier editor
decente puede configurarse para poner tabs en vez de espacios en la indentación (Dreamweaver,
Aptana, Eclipse, etc)
.cosa {
/* comentario identado con un tab */
}
5.2.4 Nombres de etiquetas, identificadores y clases.
Los nombres de etiqueta son, por supuesto, en minúscula, así como todos los demás nombres. Para
los identificadores o clases con más de dos palabras, estas serán separadas con underscore “_”.
Los nombres deben ser descriptivos, es preferible que sean un poco más largos, pero que se entienda
con sólo leer el nombre para que sirve:
body {}
#titulo_header {}
.enlace_footer {}

© 2008 Telmex S.A.
6 Sugerencias de seguridad
6.1 Servidor
· Deshabilita toda la funcionalidades que no se vayan a utilizar.
· Desinstala los componentes que no se vayan a utilizar.
· Cerra todos los puertos posibles.
· Parchealo
6.2 SQL Server
· Preferiblemente no publicarlo a internet.
· Que el servicio corra con un usuario con privilegios minimos.
· Deshabilita toda la funcionalidades que no se vayan a utilizar.
· Utiliza siempre seguridad integrada y si es posible deshabilita seguridad mixta.
· Si es posible deshabilita acceso remoto.
· Parchealo
6.3 IIS
· Que el Application Pool sea ejecutado con un usuario con privilegios minimos.
· Deshabilita toda la funcionalidad que no se vayan a utilizar.
· Deshabilita las extensiones que no se vayan a utilizar
· Los usuarios para acceso anonimo del web site deben tener los privilegios minimos.
· En el website deshabilita los verbos y las isapi extensions que no se vayan a utilizar
· Parchealo
6.4 Administracion de la seguridad
· Actualizarse sobre novedades en ataques y vulnerabilidades.
· Revisar logs de IIS - Servidor - SQL y cualquier aplicacion que se exponga.

© 2008 Telmex S.A.
7 Sugerencias de Oracle
7.1 Diseño de aplicaciones y modelo de datos
· Diseño de tablas simple y ajustados a las necesida de las aplicacion: procesos y consultas.
· Sentencias de SQL sencillas, y cortas, si son muy extensas probablemente exista un problema de
diseño de datos.
· Utilizar solos los indices necesarios, a mayor numero de indices mayor costo de insercion.
· Pedir a la base solo los datos necesarios, filtrando las filtas inecesarias en la where y no en la
aplicación.
· Uso normalizado de datos, evitar la duplicación.
7.1.1 Tablas
7.1.1.1 Uso de Oracle Features
· Default values:
Usando los valores por defecto en las tablas, ayuda aislar las ediciones en las operaciones por el
código de la aplicación o procedure.
Ejemplo:
CREATE TABLE t1
(
id$ INTEGER NOT NULL,
charcol CHAR DEFAULT 'Y',
datecol DATE DEFAULT SYSDATE,
strcol VARCHAR2(30) DEFAULT USER,
intcol INTEGER DEFAULT 12
);
INSERT INTO t1 (id$) VALUES (1);
-- Tambien podrias popular ciertos campos
CREATE TABLE t2
(
WHEN DATE DEFAULT SYSDATE,
db_domain VARCHAR2(200) DEFAULT SYS_CONTEXT('USERENV','DB_DOMAIN'),
HOST VARCHAR2(256) DEFAULT SYS_CONTEXT('USERENV','HOST'),
ip_address VARCHAR2(256) DEFAULT SYS_CONTEXT('USERENV','IP_ADDRESS'),
LANGUAGE VARCHAR2(256) DEFAULT SYS_CONTEXT('USERENV','LANGUAGE'),
protocol VARCHAR2(200) DEFAULT SYS_CONTEXT('USERENV',
'NETWORK_PROTOCOL'),
terminal VARCHAR2(200) DEFAULT SYS_CONTEXT('USERENV','TERMINAL')
);
· Checkconstraints:
Una "check constraint" permite especificar una condición de validación en cada fila de la tabla. Esto
es muy útil en el modelado de datos, ya que se suele omitir ciertas validaciones en las aplicaciones
Web, que se podrían anticipar en el diseño del modelo.

Sugerencias de Oracle
© 2008 Telmex S.A.
31
Ejemplo:
-- Validamos que el supplier_id este entre 100 y 9999
CREATE TABLE suppliers
( supplier_id NUMERIC(4),
supplier_name VARCHAR2(50),
CONSTRAINT check_supplier_id
CHECK (supplier_id BETWEEN 100 AND 9999)
);
-- Validamos que el supplier_name venga en Mayusculas
CREATE TABLE suppliers
( supplier_id NUMERIC(4),
supplier_name VARCHAR2(50),
CONSTRAINT check_supplier_name
CHECK (supplier_name = UPPER(supplier_name))
);
· Materialized View:
Estas vistas materializadas, a parte de almacenar la definición de la vista propiamente dicha, también
almacenan los registros que resultan de la ejecución de la sentencia SELECT que define la vista.
Como las vistas normales, la sentencia SELECT es la base de la vista, pero la sentencia SQL se
ejecuta cuando se crea la vista y los resultados se almacenan físicamente constituyendo una tabla
real que ocupa sitio en el disco duro. Esta tabla puede definirse utilizando los mismos parámetros de
almacenamiento que se pueden utilizar para una tabla normal (tablespace, etcétera). Las vistas
materializadas también admiten índices, esta funcionalidad resulta muy útil a la hora de mejorar el
rendimiento de las sentencias PLSQL o SQL que utilicen vistas.
Evidentemente, si una vista (view) utiliza muchas tablas base enlazadas de forma compleja, y dicha
vista va a ser utilizada frecuentemente, será muy conveniente definirla como una vista materializada o
materialized view. Esto contribuirá enormemente a mejorar el rendimiento de la base de datos, ya que
la sentencia SQL base de la vista sólo se ejecutará una vez.
Por otro lado, está el inconveniente de que si la vista materializada o materialized view va a tener que
reutilizarse en el futuro, entonces necesitaremos un mecanismo para actualizar o refrescar dicha vista
materializada, ya que las tablas base de la vista pueden haber sufrido modificaciones desde la
creación de la misma.

© 2008 Telmex S.A.
-- Creación de una Vista materializada
CREATE MATERIALIZED VIEW mv_emp_pk
REFRESH FAST START WITH SYSDATE
NEXT SYSDATE + 1/48
WITH PRIMARY KEY
AS
-- Query de la Vista
SELECT * FROM emp@remote_db;
-- Creación de otra Vista materializada
CREATE MATERIALIZED VIEW mv_empdept
AS
SELECT * FROM emp@remote_db e
WHERE EXISTS
(SELECT * FROM dept@remote_db d
WHERE e.dept_no = d.dept_no)
.
· Partition Tablas:
En el entorno corporativo, se suele dar que poseen bases de datos muy grandes (VLDB). Apartir de
Oracle 8.0 se ha proporcionado la característica de la tablas particionadas, es decir puede repartir
una tabla según algunos criterios.

© 2008 Telmex S.A.
33
Por ejemplo una tabla de las VENTAS con la estructura siguiente. Suponga que esta tabla contiene
millones de rows, pero todos los rows pertenecen a cuatro años solamente es decir de 1991, 1992,
1993 y 1994. Y la mayor parte del tiempo solo consultamos de cierto año, por ejemplo:
-- Ejemplo 1
SELECT SUM (amt)
FROM sales
WHERE YEAR = 1991;
-- Ejemplo 2
SELECT product, SUM (amt)
FROM sales
WHERE YEAR = 1992
GROUP BY product;
CREATE TABLE sales
(YEAR NUMBER(4),
product VARCHAR2(10),
amt NUMBER(10,2))
partition by range (year)
partition p1 values less
than (1992) tablespace u1,
than (MAXVALUE) tablespace u5;
Importante: Esto seria mas una incumbencia del equipo DBA.
· CLRIntegration:
En las nuevas versiones de Oracle, se permite registrar Assemblys con código de .NET. Esto nos
permite generar por ejemplo Store Procedures y/o Functions desde Visual Studio. Lamentablemente
no aumenta nuestra productividad, ya que el IDE solo da soporte a Sql Server, por ende, desarrolar
nuestro código compatible con PLSQL lo deberiamos hacer en otra herramienta, para posteriormente
incorporarla en nuestro proyecto .NET, para mayor información consulte el documento de Mitch
Ruebush, sobre CRL Integration.
7.1.1.2 Equilibrar la flexibilidad y la performance
· El diseño de las tablas debe ser normalizado, no obstante, en algunos casos por necesidades de
performance se recomienda duplicar columnas.
· No utilizar tablas genéricas, varias tablas lógicas dentro de una física.
7.1.2 Indices
· Utilizar Constraints: Primary Key, Unique Key, Foreing keys
· Utilizar columnas frecuentemente usadas para recuperar datos, que tengan algo nivel de cardinalidad.
· Considerar el agregado de una columna al final del indice, si frecuentemente se accede a la tabla solo

© 2008 Telmex S.A.
por ella.
· Ubicar (de ser posible) las columnas mas selectivas primero.
· Al crear un nuevo indice tener en cuenta los distintos tipos que ofrece Oracle:
· B*Tree: Standard y default, eficiente para alta cardinalidad.
El indice B-Tree es el tipo de indice mas común en una base de datos Oracle. Es el indice
default, es decir que si uno crea un indice sin especificar el tipo, Oracle lo creara de tipo B-
Tree.
La estructura de un indice B-Tree tiene la forma de un árbol invertido. Las estructuras
superiores se llaman ramas y la estructura inferior constituyen las hojas.
· Bitmap: para columnas con baja cardinalidad (lock costoso).
Los indices B-Tree almacenan rowids en las hojas del arbol. Estos índices pueden llegar a
utilizar grandes cantidades de espacio de almacenamiento. A diferencia de los indices B-
Tree, los indices de tipo Bitmap utilizan una fracción de espacio mucho menor representando
los rowids como valores binarios (on/off).
Los índices Bitmap son aconsejables en situaciones en que los diferentes valores que puede
tomar la columna son relativamente pocos. Ejemplos: sexo, estado civil, etc. Cuantos menos
valores posibles, mejor. A medida que crece la cantidad de valores posibles, aumentara el
tamaño del indice.
· Function-Based: Para datos que surgen de funciones entre columnas.
Introduce una característica virtual que cada DBA y/o el programador le encontrará utilidad, la
capacidad de poner en un índice funciones y de utilizar estos índices en la consulta.
Logrando tener funciones a medida para optimizar el rendimiento de nuestro modelo.
· Reverse Key: Para claves que surgen de secuencias, con carga masiva.
· Index Organized tables (IOT): Tablas con estructuras de indice.
7.1.3 Vistas
· Si bien ayudan a simplificar el diseño, tener en cuenta que el anidamiento de vistas puede causar un
plan de ejecución muy desfavorable, sobre todo en versiones anteriores a la 10g.
· En caso que se requiera referencias a tablas remotas, o de acceso intensivo, considerar el uso de
Materialized views.
7.1.4 Escritura de SQL
· "Parse Once execute Many", el compartir los cursores reduce el costo de CPU y optimiza el uso de
memoria.
Recomendaciones:
· Crear código genérico usando:
- Stored procedures and packages
- Database triggers
- Bibliotecas de funciones y procedimientos
· Estandarizar la escritura:
- Uso de mayúsculas y minúsculas
- Espacios en blanco
- Usar el mismo nombre para el mismo objeto de base de datos
- Usar variables bind.

© 2008 Telmex S.A.
35
7.1.5 Practicas peligrosas
7.1.5.1 Join Multiples Tablas
Solo se puede realizar joins de dos row sources a la vez, los joins con mas de dos tablas se resuelven
de la siguiente forma:
1. Se aparean dos tablas, el resultado es un row source.
2. La siguiente tabla es apareada con el row source que el surge del paso 1.
3. Se repite el paso 2 hasta finalizar con todas las tablas.

Buenas practicas para el desarrollo de aplicaciones ASP.NET & Oracle

Buenas practicas para el desarrollo de aplicaciones ASP.NET & Oracle

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Buenas practicas para el desarrollo de aplicaciones ASP.NET & Oracle

Semelhante a Buenas practicas para el desarrollo de aplicaciones ASP.NET & Oracle (20)

Último

Último (7)

Buenas practicas para el desarrollo de aplicaciones ASP.NET & Oracle