|
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:
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.
|
