Está en la página 1de 39

Introduccin a la Programacin Orientada a Objetos noviembre 24, 2010

Posted by arevalomaria in Introduccion a la Programacin. trackback Introduccin Emprender un proyecto de desarrollo de software, es un reto que nos lleva a pensar en la elaboracin de un producto final que cumpla con las caractersticas de un software exitoso: Solido, robusto, confiable, escalable, interoperable y lo mejor de todo para quienes estamos desarrollando esgenerar cdigo que pueda ser reutilizado. Bajo esta premisa surge la necesidad de trabajar con una filosofa de programacin orientada a objetos. Ahora bien, en este momento se preguntaran, una filosofa?, la respuesta es sencilla, antes de aprender a programar en un lenguaje orientado a objeto como C# o Vb.net, es importante aprender a pensar, bajo un modelo de desarrollo, con su teora y su metodologa, como lo es la programacin orientada a objetos, para encontrar una solucin a un problema que se plantee. Conceptos Fundamentales Clase: Vamos a iniciar este concepto con un ejemplo: Para construir un modelo de automvil se deben haber plasmado una serie de caractersticas y funcionalidades que estarn guiando la construccin del mismo. Cada vez que se procede a crear este mismo modelo de auto, se deber cumplir con las caractersticas y funcionalidades predefinidas. En programacin orientada a objeto, una clase define las caractersticas y comportamientos comunes de los objetos, en otras palabras la clase es el molde para la creacin de los mismos. Para nuestro ejemplo,un plano del modelo del auto es el smil de la clase auto. Aunque la clase especifica las caractersticas propias del objeto cada implementacin es nica tal como sucede en el mundo real pues el valor de sus atributos puede variar, por ejemplo el color, kilmetros recorridos, etc. Objeto: Los objetos tienen caractersticas y comportamientos que estn definidas de la clase de donde se instancian, sin embargo, aunque varios objetos provengan de una clase pueden tener identidad propia; en otras palabras: La identidad es el valor o estado de la propiedad que permite a un objeto diferenciarse de otros. En programacin orientada a objetos cada Auto se conocer como una instancia de la clase Auto.

Pilares de la Programacin Orientada a Objetos Es importante entender los cuatro pilares de la programacin orientada a objetos: abstraccin, encapsulacin, herencia y polimorfismo. Abstraccin: Como se explico anteriormente, los objetos tienen atributos o caractersticas que representan los datos asociados al mismo, estos atributos y sus valores en un momento dado, determinan el estado de un objeto. De igual forma los objetos tienen funcionalidades o comportamientos llamados mtodos en la programacin orientada a objetos. Con estos mtodos accedemos a los atributos de una manera predefinida y se implementan el comportamiento del objeto. Cuando desarrollemos un software, crearemos muchos objetos, que en algn momento vamos a requerir para resolver una situacin planteada. Es aqu donde entra el concepto de abstraccin. Con la abstraccin podremos tomar lo que hace falta de un objeto del mundo real para el sistema en un momento dado, es captar las caractersticas esenciales de un objeto, as como su comportamiento. Veamos como lo aplicamos a un ejemplo. En un taller mecnico se desea registrar los automviles que ingresan al mismo. Es decir que vamos a tomar para registro de ingreso Marca, Modelo, Ao, Cliente, Rif, Direccin Fiscal, telfono del cliente. En este Caso tomamos del objeto automvil solo los datos que necesitamos Marca, Modelo y Ao. Del Objeto Cliente, el cliente su RIF, direccin fiscal y telfono. Encapsulamiento El objetivo es meter todo en una capsula, juntar las piezas que hacen que funcione como un todo. Ejemplo meto el motor dentro del auto. Polimorfismo Lograr que un objeto se comporte como si fuese una implementacin de otra clase. Ejemplo: Un carro comportndose como una gra. Herencia Tomar caractersticas y funcionalidades definidas en otras clases. Ejemplo: Auto hereda de vehculo motorizado. Como gra tambin hereda de vehculo automotor.

Las clases no estn aisladas, sino que se relacionan entre s, formando una jerarqua de clasificacin. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes.

Propuesta de Estndar de desarrollo o codificacin (Tercera Entrega) #programacion noviembre 2, 2012


Posted by arevalomaria in Introduccion a la Programacin. 1 comment so far Caractersticas de un buen programa

Ejecucin correcta: funciona de acuerdo a las especificaciones. Ejecucin eficiente: uso mnimo de recursos de tiempo y memoria. Fcil de leer y comprender. Fcil de depurar. Fcil de mantener. Interfaz de usuario independiente de las funciones de clculo.

rbol de proyectos

Propuesta de Estndar de desarrollo o codificacin (Segunda Entrega) #programacion noviembre 2, 2012


Posted by arevalomaria in Introduccion a la Programacin. 1 comment so far

Las tcnicas de codificacin estn divididas en tres secciones:


Nombrado Documentacin Interna (Comentarios) Formato

Nombrado

El esquema de nombres es una de las ayudas ms importantes para entender el flujo lgico de una aplicacin. Un nombre debe ms bien expresar el qu que el cmo. Si se utiliza

un nombre que evite referirse a la implementacin se estar conservando la abstraccin de la estructura ya que la implementacin est sujeta a cambios, de esta manera se describe que hace la estructura y no como lo hace. Por ejemplo es ms claro nombrar un procedimiento de acceso a datos SeleccionarRegistro() que RealizarConsultaSelect(), porque lo que importa es que se supone que hace el mtodo y no como lo hace. Otra directiva es la de utilizar nombres tan largos como para que se entiendan pero a la vez tan cortos como para que no den informacin irrelevante. Estructuras (namespaces, procedimientos, clases, interfaces y propiedades)

Los nombres de todas las estructuras de cdigo deben estar en el mismo idioma. Los namespaces deben empezar por el nombre de la compaa seguido del proyecto y la capa:

Namespace Ejemplo.Contabilidad Namespace Ejemplo.Contabilidad.Core


El nombre del ensamblado y el namespace root deben ser idnticos. Evite el uso de nombre completamente cualificado El nombre de la clase y el archivo fuente deben ser iguales. En la POO es redundante incluir nombres de clases en el nombre de las propiedades de clases, como por ejemplo Rectngulo.RectnguloArea, en su lugar, utilice Rectngulo.Area, pues el nombre de la clase ya contiene dicha informacin. Utilice la tcnica verbo-sustantivo para nombrar procedimientos que ejecuten alguna operacin en un determinado objeto, como por ejemplo BuscarEmpleados(). Empiece los nombres de clase y propiedades con un nombre, por ejemplo CuentaBancaria, la primera letra de cada palabra debe ser mayscula. (PASCAL para tipos, mtodos y constantes)

Public Class SomeClass Const DefaultSize As Integer = 100 Public Sub SomeMethod() End Sub

End Class

Empiece los nombres de interfaz con el prefijo I, seguido de un nombre o una frase nominal, como IComponente, o con un adjetivo que describa el comportamiento de la interfaz, como IPersistible. Evite colocar valores explcitamente a los enum. Evite usar una funcin como parmetro en una condicin. Asigne el valor a una variable local. No use cadenas de texto en hardcode para presentar informacin a usuarios. Use archivos de recurso. Nunca use cadenas de configuracin de la aplicacin en hardcode. Use archivos de configuracin. Cuando construya cadenas de texto largas use StringBuilder No string Todos los recursos deben ser referenciados por ruta relativa.

Variables

Las variables miembro se escriben con la primera letra de cada palabra en mayscula a excepcin de las variable miembro privadas. Las Variables internas o de bloque deben ir en minscula. En el caso de las variablesmiembro privadas, se debe utilizar el prefijo m_ sumado al nombre de la variable (m_variable). Es recomendado que las variable booleanas contengan una palabra que describa su estado: puedeEliminarse, esGrande, tieneHijos, etc. Y siempre se debe referir al estado verdadero: tieneCredito en cambio de noTieneCredito Incluso para el caso de una variable de poco uso, que deba aparecer slo en unas cuantas lneas de cdigo, emplee un nombre descriptivo. Utilice nombres de variables de una sola letra, como i o j slo para ndices (ciclos for). No utilice nmeros o cadenas literales, como por ejemplo For i = 1 To 7. En su lugar, emplee constantes con nombre, del tipo For i = 1 To Enumeracion.length para que resulten fciles de mantener y comprender.

(Use el prefijo (m_) y contine con PASCAL para los miembros privados) Private Sub MyMethod(ByVal someNumber As Integer) Dim number As Integer End Sub

Parmetros

Los parmetros siguen el mismo estndar de las variables


Tablas

Cuando ponga nombres a tablas, hgalo en singular. Por ejemplo, use Empleado en lugar de Empleados. Cuando ponga nombre a las columnas de las tablas, no repita el nombre de la tabla; por ejemplo, evite un campo llamado FacturaFecha de una tabla llamada Factura. No incorpore el tipo de datos en el nombre de una columna.

Microsoft SQL Server

No ponga prefijos sp_ a los procedimientos almacenados, ya que se trata de un prefijo reservado para la identificacin de procedimientos almacenados de sistemas. Use USP_. No ponga prefijos fn_ a las funciones definidas por el usuario, ya que se trata de un prefijo reservado para funciones integradas. Use UFN_ No ponga prefijos xp_ a los procedimientos almacenados extendidos, ya que se trata de un prefijo reservado para la identificacin de procedimientos almacenados extendidos. Los nombres de los campos deben empezar por Mayscula. Evite colocar lgica en los procedimientos almacenados. ASP.Net y Web Services Evite colocar cdigo directo en la pagina use el archivo de cdigo oculto. El cdigo oculto debe llamar a un componente que es que tiene la lgica de negocio. Siempre verifique que las session variables no estn en null antes de tener acceso a ellas. Almacene las session variables en SQL Server. Habilite Smart Navigation en las paginas ASP.Net. Envuelva las session Variables en una propiedades.

Comentarios

Uno de los problemas de la documentacin de software interna es garantizar que se mantengan y actualicen los comentarios al mismo tiempo que el cdigo fuente. Aunque unos buenos comentarios en el cdigo fuente no tienen ningn valor en el tiempo de

ejecucin, resultan valiossimos para un programador que tenga que mantener una parte de software particularmente compleja.

Al principio de cada rutina, resulta til hacer comentarios estndar, repetitivos, que indiquen el propsito de la rutina, las suposiciones y las limitaciones. Un comentario repetitivo podra consistir en una breve introduccin que explicara por qu existe y qu puede hacer. Evite aadir comentarios al final de una lnea de cdigo. Evite los comentarios recargados, como las lneas enteras de asteriscos. En su lugar, utilice espacios para separar los comentarios y el cdigo. Antes de la implementacin, quite todos los comentarios temporales o innecesarios, para evitar cualquier confusin en la futura fase de mantenimiento. Use frases completas cuando escriba comentarios. Los comentarios deben aclarar el cdigo, no aadirle ambigedad. Vaya comentando al mismo tiempo que programa. Evite comentarios superfluos o inapropiados, como comentarios divertidos al margen. Use los comentarios para explicar el propsito del cdigo. No los use como si fueran traducciones literales. Haga siempre comentarios al depurar errores y solucionar problemas de codificacin, especialmente cuando trabaje en equipo. Haga comentarios en el cdigo que est formado por bucles o bifurcaciones lgicas. Se trata en estos casos de reas clave que ayudarn a los lectores del cdigo fuente. Separe los comentarios de sus delimitadores mediante espacios. Cada declaracin de variable importante debe incluir un comentario en la misma lnea que describa el uso de la variable que se declara.

Formato

El formato hace que la organizacin lgica del cdigo sea ms clara. Si toma el tiempo de comprobar que el cdigo fuente posee un formato coherente y lgico, les resultar de gran utilidad a usted y a otros programadores que tengan que descifrarlo. Siga las siguientes pautas para establecer el formato:

Evite albergar mltiples clases en un solo archivo.

Establezca un tamao estndar de sangra (por ejemplo, cuatro espacios o una tabulacin) y selo siempre. Alinee las secciones de cdigo mediante la sangra predeterminada. Declare una sola variable por lnea. Agregue los namespaces en orden descendente empezando por los del sistema y terminado por los personalizados o de usuario. Una clase debe estar definida en orden descendente de la siguiente manera: Variables Miembro, Constructores, Enumeraciones, Estructuras o Clases anidadas, Propiedades y por ltimo los Mtodos. Utilice espacios antes y despus de los operadores siempre que eso no altere la sangra aplicada al cdigo: numero = 3; en vez de numero=3 Use espacios en blanco para organizar a su antojo secciones de cdigo. De tal manera que se comprenda la segmentacin del cdigo. En casos donde lo amerite utilice regiones. Cuando tenga que dividir una lnea en varias, aclare que el cdigo sigue en la lnea de ms abajo mediante un operador de concatenacin colocado al final de cada lnea, y no al principio. Siempre que sea posible, no coloque ms de una instruccin por lnea, a excepcin de los bucles. Al escribir en HTML, establezca un formato estndar para las etiquetas y los atributos; como por ejemplo, las etiquetas siempre en mayscula y los atributos en minscula Cuando escriba instrucciones SQL utilice maysculas para las palabras clave: SELECT, UPDATE, WHERE, FROM, etc. Coloque las clusulas SQL principales en lneas separadas, de modo que las instrucciones sean ms fciles de leer y editar. Siempre utilice los tipos nativos de cada lenguaje y no los del CTS. No compare strings con use string.empty. Evite comparar variables booleanas contra false o true.

if(puedeEliminarse=true) Mejor use If(puedeEliminarse)

Adicionales

Use programas para el control de Cdigo Fuente. Nunca declare una sentencia catch vaca. Evite anidar bloques try/catch. Ordene la captura de excepciones (catch) siempre en orden descendente desde la ms particular hasta la ms genrica. Siempre que sea posible prefiera la validacin al manejo de excepciones

Propuesta de Estndar de desarrollo o codificacin (Primera Entrega) #programacion noviembre 2, 2012


Posted by arevalomaria in Introduccion a la Programacin. 1 comment so far Que es un Estndar de Codificacin

Un estndar de codificacin completo comprende todos los aspectos de la generacin de cdigo. Si bien los programadores deben implementar un estndar de forma prudente, ste debe tender siempre a lo prctico. Un cdigo fuente completo debe reflejar un estilo armonioso, como si un nico programador hubiera escrito todo el cdigo de una sola vez. Al comenzar un proyecto de software, es necesario establecer un estndar de codificacin para asegurarse de que todos los programadores del proyecto trabajen de forma coordinada. Cuando el proyecto de software incorpore cdigo fuente previo, o bien cuando realice el mantenimiento de un sistema de software creado anteriormente, el estndar de codificacin debera establecer cmo operar con la base de cdigo existente. La legibilidad del cdigo fuente repercute directamente en lo bien que un programador comprende un sistema de software. La mantenibilidad del cdigo es la facilidad con que el sistema de software puede modificarse para aadirle nuevas caractersticas, modificar las ya existentes, depurar errores, o mejorar el rendimiento. Aunque la legibilidad y la mantenibilidad son el resultado de muchos factores, una faceta del desarrollo de software en la que todos los programadores influyen especialmente es en la tcnica de codificacin. El mejor mtodo para asegurarse de que un equipo de programadores mantenga un cdigo de calidad es establecer un estndar de codificacin sobre el que se efectuarn luego revisiones del cdigo de rutinas. Las tcnicas de codificacin incorporan muchos aspectos del desarrollo del software. Aunque generalmente no afectan a la funcionalidad de la aplicacin, s contribuyen a una

mejor compresin del cdigo fuente. En esta fase se tienen en cuenta todos los tipos de cdigo fuente, incluidos los lenguajes de programacin, de marcado o de consulta. En general una tcnica de codificacin no pretende formar un conjunto inflexible de estndares de codificacin. Ms bien intenta servir de gua en el desarrollo de un estndar de codificacin para un proyecto de software.
Generales

Para conservar recursos sea muy selectivo en la eleccin del tipo de dato, asegrese que el tamao de una variable no sea excesivamente grande. Por ejemplo en los ciclos for es mejor, en la mayora de las veces utilizar un tipo de dato tipo short que int. Mantenga el tiempo de vida de las variables tan corto como sea posible, esto es muy importante por ejemplo cuando se utiliza un recurso finito como una conexin a una Base de Datos. Mantenga el scope de las variables tan corto como sea posible, esto sirve para evitar confusiones, mejorar la mantenibilidad y adems minimiza la dependencia, es decir si por algn motivo se comete el error de borrar una variable es ms fcil de encontrar el error si esta tiene un scope ms pequeo. Use los procedimientos y variables con un solo propsito. Evite crear procedimientos multipropsito que lleven a cabo una variedad de funciones no relacionadas. Dentro de una clase, evite el uso de variables pblicas, en cambio utilice procedimientos y propiedades que accedan a dichas variables (privadas), as provee una capa de encapsulacin y brinda la posibilidad de validar valores de cambio sobre las mismas, antes de manipularlas directamente. Cuando se trabaje en un entorno web distribuido (aldea web), tenga cuidado de almacenar informacin en variables de sesin ASP ya que el estado de sesin es almacenado siempre en una sola maquina, considere mejor almacenar dicha informacin en una base de datos. No abra conexiones a datos usando credenciales especficas de usuario, ya que estas no podrn ser reutilizadas por el pool de conexiones. Evite el uso de conversin de tipos o casting ya que esto puede generar resultados imprevistos, sobre todo cuando dos variable estn involucradas en una sentencia, utilice el cast solo en situaciones triviales, cuando este no sea el caso asegure de comentar la razn por la cual lo hizo. Use siempre rutinas de manejo de excepciones

Sea especifico cuando declare objetos que puedan generar colisin, por ejemplo si tiene dos mtodos con el mismo nombre en diferentes namespaces escrbalos con el nombre completo incluyendo el del paquete. Evite el uso de variables en el mbito de aplicacin (web). Use siempre sentencias Select-Case en lugar de utilizar sentencias if-then repetitivas. Siempre que sea posible utilice polimorfismo en vez de clusulas Select.

Patrn de Arquitectura por Capas. Componentes presentes en la Capa de Lgica de Negocios marzo 20, 2011
Posted by arevalomaria in Introduccion a la Programacin. add a comment

Diseo de componentes de negocio Los componentes empresariales pueden ser la raz de las transacciones atmicas. stos implementan las reglas de negocio, y aceptan y devuelven estructuras de datos simples o complejos. Los componentes de negocio deben exponer funcionalidad de modo que sea independiente de los repositorios de datos y los servicios necesarios para realizar la tarea, y se deben componer de forma coherente desde el punto de vista del significado y transaccional. Normalmente, la lgica de negocio evoluciona y aumenta, proporcionando funcionalidad y operaciones de mayor nivel que encapsulan la lgica preexistente. Si el proceso de negocio invoca a otros en el contexto de una transaccin atmica, todos los procesos llamados deben garantizar que sus operaciones participan en la transaccin existente de modo que las

operaciones se deshagan en caso de que la lgica de negocio que realiza las llamadas se interrumpa. Si no puede implementar transacciones atmicas, se necesitar ofrecer procesos de compensacin. Algunas responsabilidades de los componentes de negocio incluyen:

Dependiendo de la arquitectura, permitir ser llamados desde las interfaces de servicio, flujos de negocio u otros componentes de negocio. Validar entradas y salidas. Exponer operaciones de compensacin. Dependiendo del diseo, realizar llamados a los componentes de la capa de acceso a datos, para obtener o actualizar los datos de la aplicacin, o llamar servicios externos. Llamar flujos de negocio u otros componentes de negocio

La siguiente figura muestra la interaccin de un componente de negocios con los dems componentes de la arquitectura:

Diseo de flujos de negocio

Cuando los procesos empresariales requieren varios pasos o transacciones de ejecucin larga, es necesario administrar el flujo de trabajo, controlando el estado de la conversacin e intercambio de mensajes con diversos servicios segn sea necesario. En la siguiente figura se muestra la interaccin de un proceso orquestado de negocios, con las interfaces de servicios, los agentes de servicios y los componentes de negocios

Diseo de interfaces de servicio En el caso que se desee exponer la funcionalidad de negocios como un servicio (siendo lo mas recomendado por permitir que el sistema desde su inicio sea integrable con otros), es necesario proporcionar un punto de entrada desacoplado de la implementacin interna. Asimismo, puede que tambin necesite exponer funcionalidad similar a clientes diferentes con requisitos de autenticacin, logging, transacciones o contratos de nivel de servicio (SLA) distintos. Puede proporcionar un punto de entrada al servicio creando una interfaz de servicios. Una interfaz de servicios es una entidad de software implementada normalmente como una fachada que controla los servicios de mapeo y transformacin para permitir la comunicacin con un servicio y aplica un proceso y una poltica de comunicacin. Una interfaz de servicios expone mtodos, a los que se puede llamar de forma individual o en una secuencia especfica para formar una conversacin que implemente una tarea de negocios. Se recomienda, que el mecanismo de comunicacin con la interfaz de servicio implemente una conversacin basada en mensajes (ej. SOAP o MSMQ), en lugar de una basada en RPC (DCOM). De esta manera se logra un desacople con los clientes. Se debe tener en cuenta a la hora de definir estos protocolos, los requerimientos de interoperabilidad con otras plataformas, la seguridad y sincrona de la comunicacin. Los requisitos de

formato de comunicacin, esquema de datos, seguridad y proceso necesarios se determinan como parte de un contrato publicado por el servicio. Este contrato proporciona la informacin que necesitan los clientes para localizar y comunicarse con la interfaz de servicios. La siguiente figura muestra como es visto un servicio en un entorno empresarial

Las siguientes son las principales responsabilidades de una interfaz de servicios:


Exponer la lgica de negocios a la capa de presentacin, o servicios externos Servir como raz de las transacciones atmicas que envuelven las operaciones de negocio. Servir como punto de captura y registro (logging) por defecto de cualquier excepcin que haya surgido durante el llamado a los dems componentes de la cada de negocios y acceso a datos. Implementar los controles de seguridad requeridos por las llamadas (autenticacin, autorizacin y auditoria). Implementar funciones de cache de datos con frecuente consulta.

Si se necesita crear un sistema que pueda ser invocado a travs de mecanismos (protocolos) diferentes, se debe agregar una fachada entre la lgica de negocios y la interfaz de servicios. Al implementar esta fachada, se puede consolidar el cdigo relacionado con las polticas (como la autorizacin, la auditora y las validaciones, entre otros) de modo que se pueda utilizar por parte de varias interfaces de servicios que traten con diversos canales. Esta fachada ofrece una mayor facilidad de mantenimiento debido a que asla los cambios en los mecanismos de comunicacin de la implementacin de los componentes empresariales, tal como se muestra en la siguiente figura de ejemplo.

Tomado con fines Educativos de la Guia de Patrones, Practicas y Arquitectura .NET, Autores: Ernesto Marquina, Jose David Parra. Microsoft Services.

Patrn de Arquitectura por Capas. Componentes presentes en la Capa de Presentacin marzo 20, 2011
Posted by arevalomaria in Introduccion a la Programacin. 2 comments

Diseo de Componentes de Interfaz de Usuario Las interacciones ms complejas conllevan el diseo de componentes de proceso de interfaz que permiten organizar los elementos de la interfaz y controlar la interaccin con el usuario. Los componentes de proceso de interfaz resultan especialmente tiles cuando la interaccin del usuario sigue una serie de pasos predecibles, como al utilizar un asistente (Wizard) para realizar una tarea determinada. Cuando un usuario interacta con un elemento de interfaz de usuario, un evento es generado que llama cdigo en una funcin controladora. Esta funcin, a su vez hace un llamado a los componentes de negocio, para implementar las acciones deseadas y obtener cualquier dato necesario que requiere ser mostrado. Finalmente, la funcin controladora actualiza la interfaz de usuario. De esta manera, estamos separando el cdigo de la Vista y el Controlador. Esto ayuda mucho en el mantenimiento de esta capa.

Segn el diagrama anterior, la Vista hara parte de los Componentes de Interfaz de Usuario, mientras que el controlador hara parte de los Componentes de Proceso de Interfaz. Las siguientes son las principales responsabilidades de los componentes de interfaz de usuario:

Comunicacin con el usuario (entradas y visualizacin rendering de los resultados) Realizar el formateo de valores (como el formato adecuado de las fechas). Interpretar los eventos y acciones del usuario, y llamar la funcin correspondiente del controlador. Limitar entradas y validaciones de informacin. Por ejemplo, un campo Quantity puede limitar las entradas del usuario a valores numricos. Transformaciones simples sobre la informacin digitada por el usuario Almacenamiento de datos en cach. En ASP.NET, se puede especificar el almacenamiento en cach de la salida de un componente determinado de la interfaz de usuario para evitar el continuo procesamiento del mismo. Paginacin de informacin. Es frecuente, especialmente en las aplicaciones Web, mostrar largas listas de datos como conjuntos paginados.

Personalizar el aspecto de la aplicacin en funcin de las preferencias del usuario o el tipo de dispositivo de cliente utilizado (aplicaciones mviles).

Cliente Web o Cliente Windows? Bsicamente existen dos tipos de clientes en las aplicaciones empresariales, los que utilicen formas Web (Web Forms) y los que utilicen Formas Windows (WinForms). A continuacin se muestra una tabla con las ventajas y desventajas de cada una de ellas y cuando pueden ser utilizadas:
Web Forms Despliegue automtico WinForms Siempre requiere que la primera y nuevas versiones sean instaladas en el disco de la maquina cliente. .NET incluye una caracterstica llamada SmartClient que baja automticamente las nuevas versiones de assemblies a la maquina desde un servidor Web central. Algunos puntos a tener en cuenta:

El tamao de los assemblies en .NET es muchsimo menor que en Visual Basic, lo que agilizara la transferencia por la red. .NET a diferencia de COM, no requiere el registro de Dynamic Link Libraries (DLLs) o componentes, que anteriormente complicaban considerablemente la instalacin en cliente. En el caso de no poderse bajar la nueva versin, la aplicacin se inicia con la versin ms reciente en disco. Recuerde que por la arquitectura de capas, solamente si fueron hechos cambios en la interfaz de usuario, ser necesario actualizar la versin en el cliente. Segn el punto anterior, la capa de presentacin debe ser lo ms delgada posible, con solo cdigo de interfaz y validaciones simples. Pero con la autonoma suficiente, y as que no dependa completamente de los componentes de

negocio (y por consiguiente de los tiempos de red). Solo requiere tener instalado previamente el Framework de .NET. La plataforma de hardware y software actual lo soporta sin problemas.
Cualquier interaccin con el usuario requiere un viaje completo al servidor Web. Es completamente dependiente del servidor. Un modelo de eventos limitado, complica la programacin en cliente (scripts). Por lo anterior, el tiempo de respuesta de la aplicacin depende en todo momento de la red. Una interfaz de usuario con el mejor tiempo de respuesta y ms fcil de programar

Por su modelo basado en servidor, la Fcil interaccin con otras aplicaciones interaccin con otras aplicaciones ejecutndose ejecutndose en la maquina cliente en la mquina de cliente es bastante complicada. Muy seguramente requiere el desarrollo de controles, lo que complica el deployment La aplicacin depende completamente de la red Muchas operaciones pueden ser desarrolladas y el servidor. Lo que ocasiona un gran consumo localmente, lo que disminuye el consumo de red. Todo el trfico de red se reduce a llamados del ancho de banca de la red. remotos y datos Manejo del estado del usuario se hace en el servidor El estado se almacena en cada cliente. Esto aumenta considerablemente la escalabilidad del sistema Soporte completo a impresin y reportes

Capacidades limitadas de impresin.

Acceso a componentes lgicos de acceso a datos desde la interfaz de usuario Las interfaces de usuario de determinadas aplicaciones necesitan procesar los datos disponibles como consultas expuestas por los componentes de de acceso a datos. Un ejemplo muy comn de este escenario se presenta cuando necesitamos llenar una lista (ListBox, DataGrid, ComboBox, etc.) con informacin que cambia muy poco (departamentos, ciudades, oficinas, etc.). En estos casos, sera poco eficiente encapsular el acceso a los datos a travs de la capa de negocios (que aadira ningn valor), y no permitir un acceso directo.

El acceso directo a los componentes de acceso a datos desde la interfaz de usuario parece contradecir el concepto de disposicin en capas. No obstante, resulta til en este caso considerar a la aplicacin como un servicio homogneo; se llama a la aplicacin y sta decide cules son los componentes internos ms adecuados para responder a una solicitud determinada. Esta decisin se puede tomar si se est dispuesto a acoplar los mtodos y esquemas de acceso a datos con la semntica de la interfaz de usuario. Esta relacin requiere el mantenimiento conjunto de los cambios de la interfaz de usuario y de los esquemas. Diseo de componentes de proceso de interfaz La interaccin del usuario con la aplicacin puede seguir un proceso predecible. Por ejemplo, puede que la aplicacin comercial de ejemplo requiera que los usuarios escriban los datos de los productos, vean el precio total, escriban los detalles de pago y, finalmente, escriban la informacin relativa a la direccin del pedido. Este proceso conlleva la visualizacin y aceptacin de la entrada de un nmero de elementos de interfaz de usuario, y el estado del proceso (los productos solicitados y los detalles de las tarjetas de crdito, entre otros) se debe mantener en la transicin de un paso a otro del proceso. Para facilitar la coordinacin del proceso de usuario y controlar el mantenimiento del estado requerido al visualizar varias pginas o formularios de la interfaz de usuario, es necesario crear componentes de proceso de interfaz. La siguiente figura muestra los componentes de proceso de interfaz pueden ser compartidos por cada uno de las implementaciones de interfaz de usuario que tiene la aplicacin.

Los componentes de proceso de interfaz se implementan normalmente como clases .NET que exponen mtodos a los cuales pueden llamar las interfaces de usuario. Cada mtodo encapsula la lgica necesaria para realizar una accin especfica en el proceso de usuario. La interfaz de usuario crea una instancia del componente del proceso de interfaz y la utiliza para efectuar la transicin a travs de los pasos del proceso. El diseo de componentes de proceso de interfaz para su uso por parte de varias interfaces da lugar a una implementacin ms compleja, debido al aislamiento de los problemas especficos de los dispositivos. Las siguientes son las principales responsabilidades de los componentes de proceso de interfaz:

Separan el flujo de la interaccin del usuario de la implementacin o dispositivo en el que ocurre. Realizan el seguimiento del estado actual de la interaccin del usuario. Encapsulan el modo en que las excepciones pueden afectar al flujo de proceso de usuario.

Proporcionan un modo simple de combinar los elementos de la interfaz de usuario en los flujos de interaccin del usuario sin que sea necesario volver a desarrollar el flujo de datos ni la lgica de control.

En resumen, la separacin de la funcionalidad de interaccin del usuario en componentes de interfaz y proceso de interfaz conlleva las siguientes ventajas:

El estado de la interaccin de usuario de ejecucin larga se mantiene ms fcilmente, lo que permite el abandono y la reanudacin de la interaccin, probablemente incluso utilizando una interfaz de usuario diferente. Por ejemplo, un cliente podra agregar varios elementos a un carro de compra utilizando la interfaz de usuario basada en el Web y, a continuacin, llamar a un representante de ventas para completar el pedido. Varias interfaces de usuario pueden utilizar el mismo proceso. Por ejemplo, en la aplicacin comercial de ejemplo, se puede utilizar el mismo proceso de usuario para agregar un producto a un carro de compra tanto desde la interfaz de usuario basada en el Web como desde la aplicacin basada en Windows Forms.

Tomado con fines Educativos de la Guia de Patrones, Practicas y Arquitectura .NET, Autores: Ernesto Marquina, Jose David Parra. Microsoft Services.

Componentes de un Patrn de Arquitectura por Capas marzo 20, 2011


Posted by arevalomaria in Introduccion a la Programacin. add a comment

Los tipos de componentes identificados en el escenario de ejemplo son: 1. Componentes de interfaz de usuario. La mayor parte de las soluciones necesitan ofrecer al usuario un modo de interactuar con la aplicacin. En un ejemplo de aplicacin comercial de ejemplo, un sitio Web permite al cliente ver productos y realizar pedidos, y una aplicacin basada en Windows permite a los representantes de ventas escribir los datos de los pedidos de los clientes que han telefoneado a la empresa. Las interfaces de usuario se implementan utilizando formularios de Windows Forms, pginas ASP.NET, controles u otro tipo de tecnologa que permita procesar y dar formato a los datos de los usuarios, as como adquirir y validar los datos entrantes procedentes de stos. 2. Componentes de proceso de interfaz. En un gran nmero de casos, la interaccin del usuario con el sistema se realiza de acuerdo a un proceso predecible. Por ejemplo, en una aplicacin comercial, se podra implementar un procedimiento que permita ver los datos del producto. De este modo, el usuario puede seleccionar de una lista de categoras de productos disponibles y, a continuacin, elegir uno de los productos de la categora seleccionada para ver los detalles correspondientes. Del mismo modo, cuando el usuario realiza una compra, la interaccin sigue un proceso predecible de recoleccin de datos por

parte del usuario, por el cual ste en primer lugar proporciona los detalles de los productos que desea adquirir, a continuacin los detalles de pago y, por ltimo, la informacin para el envo. Para facilitar la sincronizacin y organizacin de las interacciones con el usuario, resulta til utilizar componentes de proceso de interfaz de usuario individuales. De este modo, el flujo del proceso y la lgica de administracin de estado no se incluye en el cdigo de los componentes de interfaz de usuario, por lo que varias interfaces (Web, Windows, Mvil, etc.) podrn utilizar el mismo motor de interaccin bsica. 3. Flujos de negocio. Una vez que el proceso de interfaz ha recopilado los datos necesarios, stos se pueden utilizar para ejecutar un proceso de negocios. Por ejemplo, tras enviar los detalles del producto, el pago y el envo a la aplicacin comercial, puede comenzar el proceso de cobro del pago y preparacin del envo. Gran parte de los procesos de negocio conllevan la realizacin de varios pasos, los cuales se deben organizar y llevar a cabo en un orden determinado. Por ejemplo, el sistema empresarial necesita calcular el valor total del pedido, validar la informacin de la tarjeta de crdito, procesar el pago de la misma y preparar el envo del producto. El tiempo que este proceso puede tardar en completarse es indeterminado, por lo que sera preciso administrar las tareas necesarias, as como los datos requeridos para llevarlas a cabo. Los flujos de trabajo de negocio definen y coordinan los procesos de negocio de varios pasos de ejecucin larga y se pueden implementar utilizando herramientas de administracin de procesos de negocios, como BizTalk Business Process Management u otras herramientas se encargan de automatizar flujos y procesos de negocio. 4. Componentes de negocio. Independientemente de si el proceso de negocios consta de un nico paso o de un flujo de trabajo organizado, la aplicacin requerir probablemente el uso de componentes que implementen reglas de negocio y realicen tareas de negocio. Por ejemplo, en la aplicacin comercial, se deber implementar una funcionalidad que calcule el precio total del pedido y agregue el costo adicional correspondiente por el envo del mismo. Los componentes de negocio implementan la lgica de negocio de la aplicacin. 5. Agentes de servicios. Cuando un componente de negocio requiere el uso de la funcionalidad proporcionada por un servicio externo, tal vez sea necesario hacer uso de componentes que administren la semntica de la comunicacin con dicho servicio. Por ejemplo, los componentes de negocio de la aplicacin comercial descrita anteriormente podra utilizar un agente de servicios para administrar la comunicacin con el servicio de autorizacin de tarjetas de crdito y utilizar un segundo agente de servicios para controlar las conversaciones con el servicio de mensajera. Los agentes de servicios permiten aislar las particularidades de las llamadas a varios servicios desde la aplicacin y pueden proporcionar servicios adicionales, como el mapeo del formato de los datos que expone el servicio al formato que requiere la aplicacin. 6. Interfaces de servicios. Para exponer lgica de negocios como un servicio, es necesario crear interfaces de servicios que soporten los contratos de comunicacin (comunicacin basada en mensajes, formatos, protocolos, seguridad y excepciones, entre otros) que requieren los clientes. Por ejemplo, el servicio de autorizacin de tarjetas de crdito debe exponer una interfaz de servicios que describa la funcionalidad que ofrece el

servicio, as como la semntica de comunicacin requerida para llamar al mismo. Las interfaces de servicios tambin se denominan fachadas de negocios. 7. Componentes de acceso a datos. La mayora de las aplicaciones y servicios necesitan obtener acceso al repositorio de datos en un momento determinado del proceso de negocios. Por ejemplo, la aplicacin empresarial necesita recuperar los datos de los productos de una base de datos para mostrar al usuario los detalles de los mismos, as como insertar dicha informacin en la base de datos cuando un usuario realiza un pedido. Por lo tanto, es razonable abstraer la lgica necesaria para obtener acceso a los datos (y la estructura como estn estos almacenados) en una capa independiente de componentes de acceso a datos, ya que de este modo se centraliza la funcionalidad de acceso a datos y se facilita la configuracin y el mantenimiento de la misma. 8. Entidades de negocio. La mayora de las aplicaciones requieren el paso de datos entre distintos componentes. Por ejemplo, en la aplicacin comercial es necesario pasar una lista de productos de los componentes de acceso a datos a los componentes de interfaz de usuario para que ste pueda visualizar dicha lista. Los datos se utilizan para representar entidades de negocio del mundo real, como productos o pedidos. Las entidades de negocio que se utilizan de forma interna en la aplicacin suelen ser estructuras de datos, como DataSets de ADO.NET, DataReader o secuencias XML, aunque tambin se pueden implementar utilizando clases personalizadas que representan entidades del mundo real necesarias para la aplicacin, como productos, pedidos, o clientes. 9. Verticales de seguridad, administracin operacional y comunicaciones. La aplicacin probablemente utilice tambin componentes para realizar la administracin de excepciones, autorizar a los usuarios a que realicen tareas determinadas y comunicarse con otros servicios y aplicaciones. Tomado con fines Educativos de la Guia de Patrones, Practicas y Arquitectura .NET, Autores: Ernesto Marquina, Jose David Parra. Microsoft Services.

Categoras de Patrones marzo 19, 2011


Posted by arevalomaria in Introduccion a la Programacin. add a comment

Si hacemos una revisin cercana a patrones existentes podemos revelar que estos cubren diferentes rangos de escalas y niveles de abstraccin. Algunos patrones ayudan a estructurar un sistema en subsistemas base. Mientras otros ayudan al afinamiento de subsistemas y componentes, o las relaciones entre estos. Mientras que otros ayudan en la implementacin en aspectos de diseo particulares en un lenguaje de programacin especifico. Los patrones tambin van desde aquellos independientes del dominio, como aquellos que desacoplan componentes que interactan, hasta el manejo de aspectos especficos al dominio, como polticas de transacciones en aplicaciones de negocio, o el enrutamiento de llamadas en telecomunicaciones. Segn lo anterior, se definen las siguientes tres categoras de patrones:

Patrones de Arquitectura Patrones de Diseo Patrones de Implementacin (Idiomas)

Los Patrones de Arquitectura Expresa un esquema fundamental de organizacin estructural para sistema de software. Donde provee una serie de subsistemas predefinidos, especificando sus responsabilidades, e incluye reglas y guas para organizar las relaciones entre ellos. Bsicamente, un patrn de arquitectura es una plantilla para una arquitectura de aplicaciones. Estos especifican las propiedades generales a la estructura del sistema, y repercuten la arquitectura de sus subsistemas. La seleccin de un patrn de arquitectura es por lo tanto una decisin fundamental al desarrollar un sistema de software. El patrn Modelo-VistaControlador (MVC) es uno de los ejemplos ms conocidos de un patrn de arquitectura, y provee la infraestructura para sistemas interactivos. Por estas caractersticas, los patrones de arquitectura son utilizados durante la etapa de definicin de arquitectura de un sistema. Los Patrones de Diseo Los subsistemas dentro de una arquitectura de software, al igual que sus interrelaciones, consisten normalmente de unidades arquitectnicas ms pequeas. Describimos estas unidades a travs de Patrones de Diseo. Un Patrn de Diseo define un esquema de refinamiento de los subsistemas o componentes dentro de un sistema, o las relaciones entre estos. Este describe una estructura comn y recurrente de componentes interrelacionados, que resuelve un problema general de diseo dentro de un contexto particular. Los patrones de diseo trabajan a una escala intermedia. Son menores en escala que un patrn de arquitectura, pero logran ser independientes del lenguaje de programacin. La aplicacin de un patrn de diseo no tiene efectos sobre la estructura fundamental del sistema (arquitectura), pero puede tener una fuerte influencia sobre la arquitectura de un subsistema. Un ejemplo concreto de patrones de diseo es el de Singleton o Facade. Por lo anterior, los patrones de diseo son utilizados durante la fase de diseo de un sistema. Patrones de Implementacin Un patrn de implementacin (tambin llamado Idioma ) es un patrn de bajo nivel especfico a un lenguaje de programacin. Este describe como implementar aspectos particulares de componentes o sus relaciones utilizando las caractersticas de un lenguaje dado. Los patrones de implementacin representan el nivel ms bajo de patrones, y manejan aspectos tanto de diseo como implementacin, y son mayormente utilizados durante la fase de desarrollo de un sistema. Frecuentemente, el mismo patrn de implementacin se ve diferente al ser implementado sobre lenguajes distintos, y algunas veces un patrn de implementacin muy til en un lenguaje no tiene sentido sobre otro. Por

estas caractersticas, los patrones de arquitectura son utilizados durante la etapa de definicin de arquitectura de un sistema. Patrn de Arquitectura por Capas El patrn de arquitectura por capas es una de las tcnicas ms comunes que los arquitectos de software utilizan para dividir sistemas de software complicados. Esto se ve en arquitectura de hardware, redes (por ejemplo, FTP funciona encima de TCP, la cual a su vez funciona encima de IP, y esta sobre Ethernet). Al pensar un sistema en trminos de capas, se imaginan los principales subsistemas de software ubicados de la misma forma que las capas de un pastel, donde cada capa descansa sobre la inferior. En este esquema la capa ms alta utiliza varios servicios definidos por la inferior, pero esta ltima es inconsciente de la superior. Adems, normalmente cada capa oculta las capas inferiores de las superiores a sta. Aunque este ltimo comportamiento algunas veces es vlido obviar. La siguiente figura muestra un esquema bsico de una arquitectura siguiendo este patrn.

Partir un sistema en capas tiene una cantidad importante de beneficios: Se puede entender una capa como un todo sin considerar las otras.

Las capas se pueden sustituir con implementaciones alternativas de los mismos servicios bsicos. Se minimizan dependencias entre capas. Las capas posibilitan la estandarizacin de servicios.

Luego de tener una capa construida, puede ser utilizada por muchos servicios de mayor nivel. Sin embargo, un modelo de capas tambin trae consigo algunos inconvenientes que deben ser tenidos en cuenta en el diseo:

No todo es encapsulado de la mejor manera en un modelo de capas. Como resultado se pueden generar algunas veces cambios en cascada. Demasiadas capas pueden generar problemas de rendimiento.

Pero la parte ms difcil de una arquitectura basada en este modelo es decidir que capas implementar y que responsabilidad debe tener cada una. A continuacin la discusin se centra en describir las tres capas principales de un patrn de arquitectura por capas. Capa de Presentacin Referente a la interaccin entre el usuario y el software. Puede ser tan simple como un men basado en lneas de comando o tan complejo como una aplicacin basada en formas. Su principal responsabilidad es mostrar informacin al usuario, interpretar los comandos de este y realizar algunas validaciones simples de los datos ingresados. Lgica de Negocios Tambin denominada Lgica de Dominio [FOWLER], esta capa contiene la funcionalidad que implementa la aplicacin. Involucra clculos basados en la informacin dada por el usuario y datos almacenados y validaciones. Controla la ejecucin de la capa de acceso a datos y servicios externos. Se puede disear la lgica en la capa de negocios para su uso directo por parte de componentes de presentacin o su encapsulamiento como servicio y llamada a travs de una interfaz de servicios, que coordina la conversacin con los clientes del servicio e invoca cualquier flujo o componente de negocio. Lgica de Acceso a Datos Esta capa contiene la lgica de comunicacin con otros sistemas que llevan a cabo tareas por la aplicacin. Estos pueden ser Monitores Transaccionales, otras aplicaciones, sistemas de mensajera, etc. Para el caso de aplicaciones empresariales, generalmente est representado por una base de datos, que es responsable por el almacenamiento persistente de informacin. Esta capa debe abstraer completamente a las capas superiores (negocio) del dialecto utilizado para comunicarse con los repositorios de datos (PL/SQL, Transact-SQL, etc.). Tomado con fines Educativos de la Guia de Patrones, Practicas y Arquitectura .NET, Autores: Ernesto Marquina, Jose David Parra. Microsoft Services.

Ejemplo Introduccion a la Programacion Orientada a Objeto en .NET diciembre 20, 2010


Posted by arevalomaria in Introduccion a la Programacin. 53 comments

Con la finalidad de entender todos los conceptos explicados en este blog sobre Introduccin a la Programacin Orientada a Objetos se les coloca a continuacin un link con el cdigo completo de un programa para hacerle tanto mantenimiento a las tablas de Alumnos e Instructores, como ejecutar el envo de notificaciones a ambos. La estructura del programa cumple con el modelo en capas donde se separan claramente las entidades de negocio, las reglas, las capas de persistencia, presentacin. Link Codigo Fuente: http://dl.dropbox.com/u/8067930/MVA/MVAEscuela.zip Link Script BD: http://dl.dropbox.com/u/8067930/MVA/MVAEscuelaDB_Script.zip Para finalizar la grafica del Diagrama de Componente para este ejemplo:

Ejemplo Polimorfismo diciembre 20, 2010


Posted by arevalomaria in Introduccion a la Programacin. 40 comments

En los ejemplos anteriores pudimos analizar las Clases Alumno e Instructor. En este ejemplo veremos que se desarrollo un formulario para enviar notificaciones. En este caso tanto alumno como instructor se comportaran como persona. Esto es lo que se conoce como Polimorfismo. using System; using System.Collections.Generic; using System.Linq;

using System.Web; using System.Web.UI; using System.Web.UI.WebControls; using System.Net.Mail; using MVAEscuela.Core.BE; using MVAEscuela.Core.BLL; public partial class Notificacion : System.Web.UI.Page { Alumno_BLL m_Alumno_BLL = new Alumno_BLL(); Instructor_BLL m_Instructor_BLL = new Instructor_BLL(); protected void Page_Load(object sender, EventArgs e) { } protected void Done_Click(object sender, ImageClickEventArgs e) { if (chkAlumnos.Checked) { Noixno.Common.CommonList<Instructor> Instructores = m_Instructor_BLL.GetAll(null); foreach (Instructor instructor in Instructores) { Notificar(instructor); } } if (chkInstructor.Checked) { Noixno.Common.CommonList<Alumno> Alumnos = m_Alumno_BLL.GetAll(null); foreach (Alumno alumno in Alumnos) { Notificar(alumno); } } } //Polimorfismo ya quede recibir un instructor o un alummo ya que ambos heredan de persona protected void Notificar(Persona persona) { string Cuerpo = @"<HTML><body><table border =1><tr><td>Estimado: " +

persona.Nombre + "</td></tr> <tr><td>Estimado: " + Notificacion.Text + "</td></tr> </table></body></HTML>"; MailMessage mail = new MailMessage(); SmtpClient SmtpServer = new SmtpClient("smtp.gmail.com"); mail.From = new MailAddress("server@noixnogroup.com"); mail.To.Add(persona.CorreoElectronico); mail.Subject = " Notificacion :: MVA Escuela"; mail.IsBodyHtml = true; mail.Priority = MailPriority.High; mail.Body = Cuerpo; SmtpServer.Port = 587; SmtpServer.Credentials = new System.Net.NetworkCredential("Server@noixnogroup.com", "AmericaA00*"); SmtpServer.EnableSsl = true; try { SmtpServer.Send(mail); } catch (SmtpException ex) { info.Text = ex.Message; } catch (Exception ex) { info.Text = ex.Message; } } }

Ejemplo de Clase diciembre 20, 2010


Posted by arevalomaria in Introduccion a la Programacin. 24 comments

Como haba comentado en un post anterior, en programacin orientada a objeto, una clase define las caractersticas y comportamientos comunes de los objetos, en otras palabras la clase es el molde para la creacin de los mismos. En las Prximas lneas les presento un ejemplo de la Clase Alumno en .net La clase alumno es una abstraccin con los atributos, comportamientos bases para nuestro sistema.

using System; using Noixno.Common; namespace MVAEscuela.Core.BE { [Serializable] public partial class Alumno : Persona //Herencia { #region Private fields, to hold the state of the Alumno entity private int m_IdAlumno; private DateTime m_FechaDeNacimiento; #endregion #region Public properties, to expose the state of the entity public int IdAlumno { get { return m_IdAlumno; } set { m_IdAlumno = value; IsModified = true; } } public DateTime FechaDeNacimiento { get { return m_FechaDeNacimiento; } set { m_FechaDeNacimiento = value; IsModified = true; } } #endregion } }

Ejemplo de Clase diciembre 20, 2010

Posted by arevalomaria in Introduccion a la Programacin. trackback

Como haba comentado en un post anterior, en programacin orientada a objeto, una clase define las caractersticas y comportamientos comunes de los objetos, en otras palabras la clase es el molde para la creacin de los mismos. En las Prximas lneas les presento un ejemplo de la Clase Alumno en .net La clase alumno es una abstraccin con los atributos, comportamientos bases para nuestro sistema. using System; using Noixno.Common; namespace MVAEscuela.Core.BE { [Serializable] public partial class Alumno : Persona //Herencia { #region Private fields, to hold the state of the Alumno entity private int m_IdAlumno; private DateTime m_FechaDeNacimiento; #endregion #region Public properties, to expose the state of the entity public int IdAlumno { get { return m_IdAlumno; } set { m_IdAlumno = value; IsModified = true; } } public DateTime FechaDeNacimiento { get { return m_FechaDeNacimiento; } set { m_FechaDeNacimiento = value;

IsModified = true; } } #endregion } }

Ejemplo de Herencia diciembre 20, 2010


Posted by arevalomaria in Introduccion a la Programacin. trackback

En el ejemplo que se muestra para la definicin de la Clase Instructor se toman caractersticas y funcionalidades definidas en otra clase denominada Persona. Las clases no estn aisladas, sino que se relacionan entre s, formando una jerarqua de clasificacin. Esto se conoce como herencia. using System; using Noixno.Common; namespace MVAEscuela.Core.BE { [Serializable] public partial class Instructor : Persona //Herencia { #region Private fields, to hold the state of the Instructor entity private int m_IdInstructor; private DateTime m_FechaIngreso; #endregion #region Public properties, to expose the state of the entity public int IdInstructor { get { return m_IdInstructor; } set { m_IdInstructor = value; IsModified = true; } } public DateTime FechaIngreso {

get { return m_FechaIngreso; } set { m_FechaIngreso = value; IsModified = true; } } #endregion } }

Ejemplo Polimorfismo diciembre 20, 2010


Posted by arevalomaria in Introduccion a la Programacin. trackback

En los ejemplos anteriores pudimos analizar las Clases Alumno e Instructor. En este ejemplo veremos que se desarrollo un formulario para enviar notificaciones. En este caso tanto alumno como instructor se comportaran como persona. Esto es lo que se conoce como Polimorfismo. using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.UI; using System.Web.UI.WebControls; using System.Net.Mail; using MVAEscuela.Core.BE; using MVAEscuela.Core.BLL; public partial class Notificacion : System.Web.UI.Page { Alumno_BLL m_Alumno_BLL = new Alumno_BLL(); Instructor_BLL m_Instructor_BLL = new Instructor_BLL(); protected void Page_Load(object sender, EventArgs e) { }

protected void Done_Click(object sender, ImageClickEventArgs e) { if (chkAlumnos.Checked) { Noixno.Common.CommonList<Instructor> Instructores = m_Instructor_BLL.GetAll(null); foreach (Instructor instructor in Instructores) { Notificar(instructor); } } if (chkInstructor.Checked) { Noixno.Common.CommonList<Alumno> Alumnos = m_Alumno_BLL.GetAll(null); foreach (Alumno alumno in Alumnos) { Notificar(alumno); } } } //Polimorfismo ya quede recibir un instructor o un alummo ya que ambos heredan de persona protected void Notificar(Persona persona) { string Cuerpo = @"<HTML><body><table border =1><tr><td>Estimado: " + persona.Nombre + "</td></tr> <tr><td>Estimado: " + Notificacion.Text + "</td></tr> </table></body></HTML>"; MailMessage mail = new MailMessage(); SmtpClient SmtpServer = new SmtpClient("smtp.gmail.com"); mail.From = new MailAddress("server@noixnogroup.com"); mail.To.Add(persona.CorreoElectronico); mail.Subject = " Notificacion :: MVA Escuela"; mail.IsBodyHtml = true; mail.Priority = MailPriority.High; mail.Body = Cuerpo; SmtpServer.Port = 587; SmtpServer.Credentials = new System.Net.NetworkCredential("Server@noixnogroup.com", "AmericaA00*"); SmtpServer.EnableSsl = true;

try { SmtpServer.Send(mail); } catch (SmtpException ex) { info.Text = ex.Message; } catch (Exception ex) { info.Text = ex.Message; } } }

Ejemplo Introduccion a la Programacion Orientada a Objeto en .NET diciembre 20, 2010


Posted by arevalomaria in Introduccion a la Programacin. trackback

Con la finalidad de entender todos los conceptos explicados en este blog sobre Introduccin a la Programacin Orientada a Objetos se les coloca a continuacin un link con el cdigo completo de un programa para hacerle tanto mantenimiento a las tablas de Alumnos e Instructores, como ejecutar el envo de notificaciones a ambos. La estructura del programa cumple con el modelo en capas donde se separan claramente las entidades de negocio, las reglas, las capas de persistencia, presentacin. Link Codigo Fuente: http://dl.dropbox.com/u/8067930/MVA/MVAEscuela.zip Link Script BD: http://dl.dropbox.com/u/8067930/MVA/MVAEscuelaDB_Script.zip Para finalizar la grafica del Diagrama de Componente para este ejemplo: