Make your own free website on Tripod.com

Arquitectura de tres capas con Access

SEGUNDA CAPA: LÓGICA DE NEGOCIO

 

Toda aplicación tiene código para implementar reglas de negocios, procesos relacionados a los datos o cálculos y otras actividades relativas a los negocios. Colectivamente este código es considerado para formar la capa de negocios. Otra vez, uno de los principios del diseño lógico cliente/servidor, la lógica de negocios debe mantenerse separada de la capa de presentación y de los servicios de datos. Esto no significa necesariamente que la lógica de negocios está en cualquier parte, por el contrario, esta separación es en un sentido lógico.

Hay muchas formas de separar la lógica de negocios. En términos orientados a objetos, usted debería encapsular la lógica de negocios en un conjunto de objetos o componentes que no contienen presentación o código de servicios de datos. Teniendo separada lógicamente su lógica de negocios de ambas, la capa de presentación y servicios de datos, usted ganará en flexibilidad en término de donde usted puede almacenar físicamente la lógica de negocios. Por ejemplo, usted puede seleccionar almacenar la lógica de negocios sobre cada estación de cliente, u optar por ejecutar la lógica de negocios sobre un servidor de aplicaciones, permitiendo a todos los clientes acceder a un recurso centralizado.

Los objetos de negocios son diseñados para reflejar o representar sus negocios. Ellos se convierten en un modelo de sus entidades de negocios e interrelaciones. Esto incluye tanto objetos físicos como conceptos abstractos. Estos son algunos ejemplos de objetos del mundo real: un empleado, un cliente, un producto, una orden de compra.

Todos estos son objetos en el mundo físico, y la idea en su totalidad detrás de usar objetos de negocios de software, es crear una representación de los mismos objetos dentro de su aplicación. Sus aplicaciones pueden hacer que estos objetos interactúen unos con otros como ellos lo hacen en el mundo real. Por ejemplo, un empleado puede crear una orden de compra a un cliente que contiene una lista de productos. Siguiendo esta lógica usted puede crear objetos de negocios de una orden conteniendo el código necesario para administrarse a si mismo, así usted nunca necesitará replicar código para crear ordenes, usted solo usará el objeto. Similarmente, un objeto cliente contiene y administra sus propios datos. Un buen diseño de un objeto cliente contiene todos los datos y rutinas necesitadas para representarlo a través del negocio completo, y puede ser usado a través de toda la aplicación de ese negocio.

No toda la lógica de negocio es la misma. Alguna lógica de negocio es un proceso intensivo de datos, requiriendo un eficiente y rápido acceso a la base de datos. Otras no requieren un frecuente acceso a los datos, pero es de uso frecuente por una interfase de usuario robusta para la validación en la entrada de campos u otras interacciones de usuarios. Si nosotros necesitamos una validación al nivel de pantallas y quizás cálculos en tiempos real u otra lógica de negocios, pudiéramos considerar este tipo de lógica de negocios para ser parte de la IU, ya que en su mayor parte es usada por la interfase de usuario.

Una alternativa de solución es dividir la capa de lógica de negocios en dos:

  • Objetos de negocios de la IU.
  • Objetos de negocios de datos.

Un ejemplo del objeto Empleado de la capa objetos de negocios de la IU proveerá propiedades y métodos para usar por el diseñador de la interfase de usuario. Ejemplo de propiedades y métodos pudieran ser: IDEmpleado, Nombre, Dirección, etc., y como métodos crear una de compra, etc. El objeto Empleado de la capa de objetos de negocios de datos será responsable de los mecanismos de persistencias, interactuar con la base de datos. Los objetos de esta capa son considerados sin estado, solo poseen métodos.

 

 

 

Home | Diseño Aplicaciones |