EssentialFox 2003
Inicio

Viernes 25/04

Sábado 26/04

Domingo 27/04

Lunes 28/04

Galerías

 

... a Conferencias
 
Anuncios




 
© PortalFox

EssentialFox 2003

Sesión: Necesita una Base de Datos?
Presentado por: Jim Booth
 
Jim Booth es uno de los gurus de Visual FoxPro, actualmente es el jefe de desarrollo de eMedice.com, co-autor de varios libros de VFP, cientos de articulos en revistas, Microsoft MVP desde 1993.
 
Descripción: En el mundo actual de administracion de datos nos encontramos con decisiones que debemos tomar. Podriamos desarrollar nuestra siguiente aplicacion usando sistemas con base de datos autocontenidas como Access, o quizas Visual FoxPro y sus contenedores de base de datos y reglas de negocio?. Que tal cosas multicapas, cual base de datos debe ser usada para las viejas aplicaciones n-tier?. Ha pensado en robustez?, la lista de preguntas crece y crece. Esta sesion exploro los temas y sugerencias en la toma de decisiones.
 
Se trataron temas basicos sobre las bases de datos, empezando con las partes de conforman una base de datos:
  • Tablas
  • Indices
  • Relaciones
  • Vistas
    • Estaticas
    • Dinamicas
    • Parametrizadas
  • Data Manipulation Language (DML), el cual podriamos traducir como Lenguage de Manipulacion de Datos
  • Procedimientos Almacenados
  • Triggers
    • Insert
    • Update
    • Delete
    • Instead of
  • Llaves (Keys)
    • Primarias
    • Candidatas
    • Foraneas
Como teoria adicional, se nos dio una vista a cuales son las bases de datos (teoria pura):
  • Hojas de Calculo (Spreadsheet)
    • Microsof
    • Lotus 123
  • Autocontenidas
    • Microsft Access
  • Basadas en Archivos
    • Visual FoxPro y DBFs
    • Paradox
  • Servidores de Base de Datos
    • Microsoft SQL Server
    • Oracle
    • MySQL
Jim discutio con los asistentes, los pros y contras de cada una de las opciones arriba mencionadas, resolviendo dudas de cuando se deberia usar cada una de ellas, pero haciendo hincapie que en teoria todas las opciones son bases de datos, el como y cuando se utilicen cada uno es otra cuestion muy diferente. Como una anotacion adicional ser vio que en el hecho teorico ninguno es una base de datos relacional, parece raro?, no para nuestro MVP, pues demostro que ninguna opcion disponible en el mercado cumplia las exigencias para poderse llamar "Relacional" puesto que para ello deberia cumplir con los requisitos expuestos por la teoria relacional dada a conocer por su creador el Dr. Cood.
 
Diseño de Procesos
 
El guru paso al tema de diseño de proceso, dando la recomendacion de NO comenzar ningun proyecto de base de datos si no se tiene en su totalidad el diseño de base de datos, con esto recomendo tambien tomar en cuenta los siguientes puntos:
  • Revisar detalladamente las partes mas criticas del desarrollo de la base de datos, como lo son las entidades relacionadas, como son las vistas, tablas, etc.
  • Resolver que y cuanta informacion se recabara
  • Mejorar el Modelado de Datos tomando en cuenta las peticiones futuras, en otras palabras dejar todo preparado para los requerimentos posteriores.
Tipos de Datos
 
Con estos topicos se discutieron que tipos de datos se utilizan en las base de datos (no confundir con longitud y tipos de datos que se declaran -- integer, char, etc --), poniendolo en cuatro grupos principales:
  • Datos base (Core Data), estos son los que forzozamente tienen que ser ingresados, ya sea por medio de captura o importacion de fuente externa.
  • Datos de Procesamiento (Process Data), datos resultantes del procesamiento de los "Core Data".
  • Datos de Referencia (Reference Data), por ejemplo, datos que son utilizados solamente para hacer referencias en busquedas, no cambian con frecuencia y/o son generalmente estaticos.
  • Metadata, son los datos que explican que significan los datos anteriores, son autoexplicativos en su contexto.
En esta seccion se tomo en cuenta que en el diseño de base de datos se debe tomar en cuenta la normalizacion, pero NO deberia ser un punto base para todo, pues dependiendo de que tipo de datos se utilizaran con mas frecuencia podria desnormalizar los datos para ganar ventaja tanto en velocidad de procesamiento o almacenamiento, es decir, la normalizacion es solamente una pequeñisima parte del diseño de base de datos.
 
Reglas vs Validacion
 
Booth describio ampliamente que son las reglas (tambien no confundir con el tema de Reglas de negocios de las aplicaciones n-tier) y su diferencia con las validaciones
  • Reglas (Rules)
    • Reglas de Base de Datos (Database Rules) tambien llamados Domain Constraints
      • Empleado debe tener como edad, un numero positivo
    • Reglas de Negocios (Bussiness Rules)
      • La edad del empleado debe ser >= 18
  • Validaciones
    • Definido como el proceso de hacer que se cumplan las reglas de base de datos
Donde hacer que se cumplan las Reglas?
 
Inicialmente se puede pensar que hay que dejar que las reglas se cumplan en la base de datos,  pero en realidad hay dos lugares donde hacerlo:
  • Reglas de Base de Datos
    • Se pude exigir que estas se cumplan dentro de las bases de datos
  • Reglas de Negocios
    • Exigir que las reglas se cumplan fuera de las base de datos.
Lo anterior propicio el surgimiento de muchas dudas, si estabamos viendo diseño de base de datos y reglas de base de datos, por que entrar en reglas de negocio (esta vez refiriendose a multicapa [ n-tier ])?, pues dependiendo de que desarrollo se hara, habra que tomar en cuenta las validaciones fuera de la base de datos multiples veces, es decir tanto en la capa de base de datos, como en reglas de negocio y la capa de presentacion, llegando a las siguientes conclusiones:
  • La misma regla puede ser requerida mas de una vez, por ejemplo, si se esta haciendo un desarrollo Web, en vez de dejar que un objeto de negocio haga las validaciones, puede tomarse una validacion a nivel de usuario (por ejemplo via JavaScript), evitando de esta manera un viaje de infomacion innecesaria, ganando velocidad de procesamiento, la validacion via Bussiness Objects puede dejarse para las ocasiones en donde por algun motivo no se puede hacer una validacion a nivel presentacion, la validacion a nivel base de datos dejarla para las ocasiones en donde no se pueda utilizar la capa de presentacion.
  • Si se dejara la validacion a nivel de base de datos, lo cambios temporales o inmediatos tendrian que manejarse en todos los objetos involucrados, situacion que posiblemente no se pueda llevar a cabo, un cambio en nivel de bussiness rules puede ser mas inmediato, dandole flexibilidad al desarrollo.
  • Se vieron los tipos de requisitos de validacion:
    • Asistente (Assistive): Si se tuvieran validaciones de no dejar cierto campo sin datos, pueden procesarse y pedirle al usuario que rellene los datos faltantes.
    •  Absoluta (Absolute): Ciertos datos  pueden ser validos, pero no necesariamente cumplir las reglas, como por ejemplo, dejar que alguien deje 3 como edad de un trabajador, pero no es datos valido para que cumpla las reglas
Controlando el acceso a los datos
 
El siguiente tema que trato el prestigiado MVP fueron los relacionados con el control de acceso a los datos, englobandolos en tres grupos principales:
  • Por Usuario: determinar que puede o no hacer un usuario en forma individual
  • Por Rol: Varios usuarios pueden tener unas actividades especificas, una forma diferente de agrupar a los usuarios, dependiendo que pueden hacer, crear base de datos, modificar tablas, agregar tablas, etc.
  • Por Grupo: Agrupar a los usuario de una manera diferente, por ejemplo, dejar que algunos puedan insertar registros, modificar datos, borrar, etc.
Temas a tomar en cuenta al seleccionar bas de datos
 
Se describieron cada uno de los puntos basicos para ver cual opcion puede tomarse segun las necesidades que pueden surgir:
  • Volumen de Datos: Es conocido que todas y cada una de las opciones de base de datos tendra una limitacion tecnica, que en cada uno de los casos puede evitarse, darle vuelta o ignorarse, deben ser un punto de discusion al tratar.
  • Volumen de Transacciones: Cuanta informacion se procesara por minuto, hora o dia puede hacer que todo parezca no adecuado, la revision exaustiva de este punto evitara muchos dolores de cabeza futuros.
  • Base de Usuarios: Cuantos usuarios soportara la aplicacion es importante, puede ser monousuario, nivel de red, inclusive via internet.
  • Seguridad
    • En acceso: Pueden los usuarios tomar la informacion y moverla de lugar o robarla?
    • En seguridad intrinsica de los datos: Si se tiene acceso a la informacion, que pueden hacer con ella?, pueden agregar, modificar o borrar datos?
  • Performance: La combinacion de velocidad y opciones disponibles puede hacer que la seleccion cambie.
  • Consumo de recursos: Con recursos no solo se deben tomar en cuenta lo referente a Hardware, sino tambien los respectivos a tiempo (por ejemplo en administracion) asi como tambien al recurso humano (preparacion para manejar los datos y administracion de informacion)
  • Costo: Un parte importante, pero no definitiva, debe estudiarse a fondo si es necesario saltar de una opcion "gratuita" (como lo son las base de datos DBF de VFP) a una con costo (como lo es un servidor dedicado como Microsoft SQL Server)
Jim Booth recomendo que estas opciones no deberian ser de mutua exclusion, es decir, que no debe de llevarse solo por uno de los topicos, sino tomarle todos en cuenta, pues esto llevara a realizar un caso de exito en el proyecto.
 
Sesión: Comparacion OOP, revision Visual FoxPro vs Visual Studio .NET
Presentado por: Markus Egger
 
Markus Egger es el presidente de EPS Software Corporation, localizada en Houston, Texas, desde hace varios años ha recibido el premio Microsoft MVP, es el autor de muchas herramientas como lo es GenRepoX (dominio publico), Fox Extension Classes y Visual WebBuilder. Actualmente se concentra en consultoria en proyectos COM, orientados a objetos y aplicaciones de Internet .
 
Descripción: Los desarrolladores basados en Visual FoxPro han conocido la Programacion Basada en Objetos (OOP) por varios años. VFP tiene un gran modelo de objetos, y sus usuarios han obtenido la capacidad de utilizar estas caracteristicas (aun sin saber que lo usan). Ahora Visual Studio .NET (VS .NET y sus lenguajes asociados C# y VB.NET) tambien tiene desarrollo OOP real. Sin embargo, hay varias diferencias, en esta sesion se exploraron las principales diferencias entre estas dos plataformas de Microsoft.
 
Codigo Procedural vs OOP.
 
Se vieron las principales diferencias entre estas opciones:
  • VFP
    • Codigo Hibrido, este se puede utilizar y muchas veces sera requerido:
      • Ejemplo: dDate = DATE()
      • Ejemplo: cName2 = ALLTRIM(cName)
  • .NET
    • Todo es hecho a travez de objetos:
      • Ejemplo: dData = Date.Now
      • Ejemplo: cName2 = cName.Trim()
    • Todo es un objeto! Inclusive las cadenas (strings)!, cualquier parecido con Java es solo coincidencia !!
Definicion de Clases
 
La definicion de clases es un tema diferente, aunque muy parecido:
 
Visual FoxPro
DEFINE CLASS Customer AS Custom
 
ENDDEFINE
C#
public class Customer
{
 
}
VB .NET
Public Class Customer
 
End Class
 
Instanciamiento de Clases
 
Una vez definida la clase es necesario instanciarlo, en VFP se usa la funcion CreateObject, en VS .NET se usa new:
Visual FoxPro
LOCAL oBiz AS Customer
oBiz = CREATEOBJECT("Customer")
 
C#
 
Customer oBiz;
oBiz = new Customer;
o tambien:
Customer oBiz = new Customer();
VB .NET
 
Dim oBiz As Customer = New Customer()
 
Definicion de Metodos
 
Formas muy parecidas, pero diferente implementacion:
Visual FoxPro
FUNCTION GetCustomerName(PKCustomer)
   *** Buscar Cliente
   RETURN This.CustomerName
ENDFUNC
C#
public string GetCustomerName(string PKCustomer)
{
  //Buscar Cliente
   Return this.CustomerName;
}
VB .NET
Public Function GetCustomerName(ByVal PKCustomer as String) As String
    'Buscar Client
Return Me.CustomerName
End Function
 
Una Breve Historia sobre Propiedades
 
  • Los Objetos (Classes) tienen "miembros variables" (member variables): es aqui donde se los objetos almacenan los datos
  • Los Objetos permiten el acceso a estos miembros:
    • Inicialmente, estos accesos suceden a travez de metodos
      • Un metodo get para acceder al valor de la variable
      • Un metodo set para establecer el valor
    • Posteriormente, fue introducido el concepto de propiedades para simplificar el uso de metodos set y get:
      • Es mas natural referirse a Objeto.Color en vez de Object.GetColor() y Object.SetColor()
Cambio de Paradigma: Propiedades y Campos
  • Visual FoxPro
    • Los miembros variables y metodos Set y Get han sido combinados en "Propiedades" (Properties)
    • Esto limita a las propiedades y miembros a ser la misma entidad.
    • Posteriormente, se introdujeron los metodos access y assign
  • VS .NET
    • Los "member variables" son llamados Fields (campos)
    • Las propiedades son implementadas mediante los metodos Set() y Get()
    • Las propiedades pueden servir como una interface a los campos
Cambio de Paradigma: Metodos Encadenados
 
VFP resuelve expresiones "inside out", de derecha a izquierda:
 
Visual FoxPro
UnaCadena = "blah       "
MiCadena = ALLTRIM(Upper(UnaCadena))

 

.NET adicionalmente resuelve de "izquierda a derecha", obteniendo la capcidad de encadenar funciones del objeto en cuestion:

C#
string UnaCadena = "blah        "
string MiCadena = UnaCadena.ToUpper().Trim()
 
Cambio de Sintaxis: Herencia (Inheritance)
 
  • El comportamiento es similar
  • La sintaxis en algo diferente
  • .NET: si no se especifica la herencia, se asume la clase "objeto" como base
Visual FoxPro
DEFINE CLASS Human AS Session
ENDDEFINE
DEFINE CLASS Man AS Human
ENDDEFINE
C#
public class Human {};
public class Man : Human {};
VB .NET
Public Class Man
          Inherits Human
End Class
 
Strong Typing: Que es y que significa realmente.
 
Hay una marcada diferencia entre como maneja los objetos y variables VS .NET y VFP, este ultimo, puede cambiar entre diferentes tipos y definiciones sin ningun problema, esto mismo no es posible "directamente" en VS .NET debido a como se manejan estas cuestiones:
  • Visual FoxPro
    • En VFP7 y posteriores se introdujo el concepto  Strong Type por cuestiones de compatibilidad con el modelo COM y COM+ de Microsoft:
      • LOCAL oBizObj AS Object
        oBizObj = CREATEOBJECT("MyBizObj")
        oBizObj = "Bummer"
        oBizObj = oApp.GetAnyBizObj()
        oBizObj.InvoqueAnyMethod()
      • El Strong Typing permite la declaracion explicita del tipo de dato o clase (char, logico, objetc, date ...) mas no asi la restriccion ante cambio o asignacion a algo diferente.
      • Las clases se manejaran como objetos
  • .NET
    • Tipos y clases son el mismo concepto.
    • Para usar un tipo (clase), necesita especificarse de manera explicita y rigurosa
      Man oMarkus = new Man()
      oMarkus.GetName()
      public class Man: Human
      {  public string GetName()
              { return "Markus" }
      }
    • No permite cambiar los tipos, solo mediante "casting".
Strong Typing y la Herencia
 
Se demostro que las subclases pueden ser tratados del mismo tipo que su clase padre (parent class).
 
Man Markus = new Worker()
oMarkus.GetName()  //Funciona correctamente
oMarkus.GetProfession() // ERROR!, no se puede utilizar este metodo debido al tipo declarado
public class Worker : Man
{
     public string GetProfession
         { return "Software Developer"; }
}
 
Sobrecarga de Metodos
 
Este tema es de los mas tratados en programacion OOP, Egger explico las diferencias fundamentales:
  • En Visual FoxPro los metodos son identificados por sus nombre
  • en .NET los metodos son identificados por su firma (signature):
    • Nombre
    • Contador de Parametros
    • Tipos de Parametros
    • Tipo Retornado por el metodo
  • Por lo tanto, .NET permite duplicidad en nombre de metodos, cosa que no es posible en VFP.
  • .NET permite el paso de diferentes tipos de parametros
    • float f1 = 1.1
      System.Math.Round(f1)
      decimal d1 = 1.1
      System.Math.Round(d1) // Se ejecutara un metodo diferente!!
  • .NET permite parametros opcionales
    • float f1 = 1.44
      System.Math.Round(f1)    // Retorna 1
      System.Math.Round(f1,1) // Retorna 1.5
  • .NET permite hacer lo mismo de diferentes maneras:
    • Customer oMarkus = oCust.GetCustomer(1)
      Customer oClaudio = oCust.GetCustomer("123456")
  • .NET permite la intercepcion de un uso incorrecto de metodos
    • Customer oMarkus = oCust.GetCustomer(false) // marcara error si no hay un metodo definido con parametro logico
Cambio de Paradigma: SobreEscritura de Metodos
 
  • Visual FoxPro
    • Los metodos con el mismo nombre que la clase padre son sobreescritos
  • VS .NET
    • Los metodos necesitan ser diseñados como reescribibles mediante la clausula (metodos "virtuales")
    • Los metodos con la misma fimra (signature) pueden ...
      • ... sobreescribir metodos en clases padre
      • ... ocultar metodos de clases padre
Entendiendo los Metodos Virtuales
 
Este nuevo concepto de Metodos Virtuales fue explicado ampliamente, a continuacion codigo de ejemplo:
 
public class Hello
{
      public string Hello ()
       { return this.GetGreetings(); }
      publci string GetGreeting()
         { return "Hello"; }
}
public class World : Hello
{  
     public override string GetGreeting()
         { return base.Hello() + " World "; }
}
 
Se demostro que al instancia un objeto del tipo World, para cualquier usuario de VFP resultaria logico que el proceso de ejecucion seria el siguiente:
  1. Se ejecuta el metodo Hello de la clase base
  2. El metodo Hello::Hello mandara a llamar el metodo Hello::GetGreeting
  3. Al tener sobre escrito el metodo GetGreeting, el resultante sera "Hello World"
Lo anterior no sucede, pues si no define el metodo Hello::GetGreeting como Virtual, el resultante siempre sera "Hello", por lo tanto para tener el comportamiento esperado debera incluirse la clausula "virtual":
 
public class Hello
{
      public string Hello ()
       { return this.GetGreetings(); }
      publci string virtual GetGreeting()
         { return "Hello"; }
}
 
Por lo tanto se resumio lo siguiente:
  • En VFP todos los metodos son virtuales
  • Los metodos no virtuales son compilados en tiempo de ejecucion
  • Los metodos virtuales son tomados durante la ejecucion
    • Hay cierta sobrecarga de procesamiento en aquellos codigos que tienen que ser interpretados y producidos por el compilador en el momento de decidir el algoritmo de ejecucion.
Cambio de Paradigma: Constructores
 
El tema de constructores fue tomado a consideracion:
  • Estos metodos son ejecutados cuando el objeto es creado
  • El evento VFP:Init() podria considerarse como su constructor, pero no cumple completamente los requisitos de OOP para llamarse como tal.
  • En .NET los constructores tienen el mismo nombre que la clase en C# y en VB .NET se nombre "new":
C#
public class Customer
{
     public Customer() {}
}
VB .NET
Public Class Customer
      Public Sub New()
      End Sub
End Class
  •  Nota Importante: Debe hacer el constructor de tipo "public", de otra manera la clase no podra ser instanciada
Constructores y Sobrecarga
  • Frecuentemente los constructores son usados para configurar los objetos de manera pertinente
    • Usar diferentes versiones hacen mas facil el uso de objetos:
      • Bitmap oBmp = new Bitmap(100,100)
      • Bitmap oBmp2 = new Bitmap("test.bmp")
  • Usualmente deberia haber un constructor sin parametros sobrecargado, esto es especialmente importante para soporte de diseño.
Constructores y Herencia
 
Los constructores siempre heredan el comportamiento heredado como su primera accion:
 
C#
public class x : y
{
     public x() : y
      {
         // Aqui puede escribir el codigo
      }
}
VB .NET
Public Class x
           Inherits y
      Public Sub New()
            MyBase.New()
            ' Aqui codificar el codigo
      End Sub
End Class
 Este comportamiento es muy diferente que en VFP, pues no hay un equivalente a DODEFAULT.
 
Cambio de Paradigma: Destructores
  • Los destructores el algo parecido al evento Destroy() de las clases VFP
  • En C# se definen: ~NombredeClase
  • En VB .NET se define: Finalize
  • En .NET este evento es "No Determinante":
    • Los objetos son destruidos por la funcion Garbage Collector del .NET Framework
    • Debe tenerse cuidado, estos eventos podrian entrar en accion horas despues de que el objeto sea liberado
C#
public class Empleado
{
     public ~Empleado
      {
         // Aqui puede escribir el codigo de limpieza
      }
}
VB .NET
Public Class Empleado
      Protected Override Sub Finalize()
            MyBase.Finalize()
            ' Aqui codificar el codigo
      End Sub
End Class
 
Metodo de Limpieza: Uso de metodo Dispose()
  • Muchos objetos no pueden esperar al Collector Garbage, como por ejemplo, alguna clase de conexion de base de datos, en donde muy frecuentemente es necesario disponer de ese recurso
  • Muchos objetos implementan el metodo Dispose()
    • Esta esta definida por la interface iDosposable
  • Disponda de los objetos que haya creado, siempre y cuando posean dicho metodo

 

Todas las marcas y los logos utilizados en este sitio son propiedad de sus respectivos dueños.
Los artículos, noticias y comentarios son propiedad y responsabilidad de sus respectivos autores.
Copyright © 2000-2007 PortalFox. Todos los derechos reservados.