Trabajar con conjuntos de objetos de negocio

Trabajar con conjuntos de objetos de negocio

Trabajar con conjuntos de objetos de negocio : Multi-millones de consejos para hacer su vida mas facil.

En este articulo te muestran una forma de trabajar con conjuntos de objetos de negocio
Las Necesidades De Muchos
En este articulo vamos a volver al mundo de un objeto de proposito general el marco y la relacion completa de manejo considerando como trabajar con conjuntos o colecciones de objetos de negocio. Hasta ahora hemos visto como expresar simple 1-1 o muchos-1 relaciones de simplemente exponer el objeto relacionado como una propiedad, tales como el Orden.Cliente. Este es un simple y natural para exponer objetos relacionados, con el manejo apropiado que ocurren dentro de las funciones de descriptor de acceso de la propiedad, pero, ¿como podemos exponer a las otras variantes de relaciones, a saber: 1-muchos o muchos a muchos? Un enfoque simple, como el Cliente.El orden, no sirven a nuestro proposito, ya que implica que hay un unico Pedido para un Cliente dado (que no es generalmente el caso), y evita el acceso a las demas Ordenes que puedan existir. Lo que necesitamos es la sintaxis, y una implementacion eficiente, para el manejo de un conjunto de objetos de negocio.
Si pensamos acerca de esto en una manera diferente, a continuacion, necesitamos un proposito general significa para el manejo de un conjunto de objetos. En la practica, asi como una pequeña coleccion de objetos (tales como la lista de Pedidos para un Cliente dado que en general se componen de mas de un par de cientos de entradas) tambien quisieramos dar soporte a grandes colecciones de objetos, tales como la lista de todos los articulos de Stock. Como estamos operando en un objeto orientado al mundo, la conclusion logica es que se necesita una nueva clase que expone un conjunto de objetos de negocio. Llamemos a esta clase TPDList (una lista de objetos del Dominio del Problema) para ir con nuestros TPDObject clase. El nombre es arbitrario, y algunos pueden pensar que esto implica una implementacion particular. Por desgracia alternativas como el 'conjunto' y 'coleccion' ya tiene consecuencias similares dentro de la Delphi mundo.
azucar Sintactico
Un sintacticamente agradable y natural manera de tratar con un conjunto de objetos seria exponer el uso de algun tipo de matriz, como se muestra en el Listado 1. Ejemplo de una definicion de clase nos permitiria acceder a los objetos de uso construcciones en nuestro codigo como Cliente.Pedidos[], que es muy familiar. Sin embargo, hay dos grandes desventajas de este enfoque: esto implica que debemos saber cuantos objetos hay en la lista, y que todos ellos estan disponibles en un acceso aleatorio tipo de moda. La unica manera de asegurar que estos requisitos se cumplen, es totalmente rellenar la lista, o al menos totalmente rellenar una lista interna de ID de objeto y carga de cada objeto individualmente en que se accede. La desventaja para el primer metodo es el excesivo consumo de memoria y un posible retraso notable, mientras que la variedad de objetos que se crean instancias, y la desventaja para el segundo enfoque es el de la ineficacia de la emision de un registro de carga para cada objeto que se accede (caminar a traves de un conjunto de 100 objetos se requieren 100 consultas de base de datos para ser emitido).
Asi que, a pesar de la sintacticos beneficios de la matriz de enfoque no es la optima para el caso general, aunque, por supuesto, un marco puede ser extendida para soportar dos (o mas) diferentes formas de manejo de conjuntos de objetos, uno para pequeños y uno para los grandes. Personalmente soy un gran fan de consistencia y prefiere que haya una unica sintaxis para trabajar con conjuntos de objetos. Como veremos mas tarde en una columna, esto no nos impide tener un numero de implementaciones para esta sintaxis, atento a las diferentes circunstancias.
En el nivel mas fundamental de nuestra objetos van a ser ejecutados desde mecanismo de almacenamiento persistente, generalmente una base de datos. La mayoria de los datos que estos dias se accede a traves de una consulta (SQL) y si tenemos en cuenta las propiedades de estos elementos son generalmente capaces de proporcionar nosotros con el 'siguiente' disco conceptual, y para determinar cuando la lista esta agotado. Normalmente, la informacion tal como el numero de registros en la lista, o de acceso aleatorio para ellos, no esta disponible. Nuestro marco de trabajo debe ser diseñado con el rendimiento y la aplicacion de cliente de los requisitos de recursos en la mente, por lo que se sugiere la interfaz para nuestra TPDList se muestra en el Listado 2. Esto nos proporciona un Primer metodo (re-inicializacion de la lista de vuelta al principio), al Lado (acceso el siguiente objeto en la lista) y un IsLast de la propiedad (lo que indica cuando la lista esta agotado). El 'actual' objeto de la lista esta disponible a traves de un apropiado nombre de la propiedad. Esta interfaz puede parecer innecesariamente simple donde son los metodos para apoyar al reves de navegacion? La experiencia muestra que la navegacion a traves de una lista muy rara vez se requiere, y donde esta, se puede lograr facilmente a traves de otras construcciones. Por el momento, vamos a mantener nuestra lista de clase de gestion de simple.
¿Como es esta clase para ser implementado? Como antes, nuestro dominio del problema (objeto de negocio) de la capa debe tener ningun concepto de como se almacenan los datos o administrado. Nuestro TPDList gestiona una coleccion de objetos de negocio y por lo tanto no puede ser una envoltura alrededor de algo tan especificas de base de datos como una base de datos de consulta. En su lugar, vamos a diseñar otra clase para manejar la base de datos de soporte para listas de objetos, y proporcionar una base de objetos de base de datos independiente de la interfaz entre nuestro TPDList y esta clase. De esta manera hemos mantenido la estricta separacion entre la capa de negocio y la gestion de datos de la capa, lo que nos permite una total flexibilidad en como este es administrado.
Endulzar la pildora
De la misma manera como nuestro TPDObject habia un TDMObject de gestion de datos de corolario, puede parecer que nuestra TPDList debe tener un TDMList equivalente. En la practica, hay una gran cantidad de coincidencia entre los datos de dos clases de manejo y que puede ser subsumida en una sola clase. Esto puede parecer logico tener una jerarquia de clases con un antepasado comun para la funcionalidad comun y descendientes para manejar los casos singulares y listas, pero esto impone un codigo de escritura de sobrecarga cuando se trata de la aplicacion de nuestra aplicacion, con poco beneficio. Por lo tanto, a ampliar nuestra TDMObject a la lista de soporte de las operaciones, asi como el unico existente, instancia Cargar y Guardar.

Cada TPDList sera por lo tanto un privado TDMObject que solo es responsable de la gestion de acceso a los datos de la lista de objetos. El 'actual' TPDObject expuestos por la lista de imitar la 'actual' registro en la base de datos del cursor. Vamos a necesitar un unico (y privada) de gestion de datos de objeto para cada TPDList porque necesita mantener el estado (la informacion de la consulta, actual del cursor de registro y asi sucesivamente). Por el contrario, el problema de dominio de los objetos de la misma clase pueden compartir una unica gestion de datos de objeto debido a que la Carga y Guardar metodos son apatridas operaciones.
Nuestra TDMObject ahora puede ser extendida para soportar las operaciones necesarias. Tendra FirstRecord y NextRecord metodos (para indicar que el registro basado en la naturaleza), y un IsLastRecord propiedad para indicar cuando el cursor esta agotado (este cursor sera privado para la gestion de datos de objeto y la base en torno a algunos de la base de datos dependiente del mecanismo de consulta). Los metodos en nuestro TPDList simplemente delegar el trabajo a los datos administrar objeto, llamar a estos nombres parecidos metodos. El TPDList pide a la privada la gestion de los datos objeto de dotarla de una instancia del problema objeto de dominio como la aplicacion de cliente de los pasos a traves de ella. El codigo para llenar este objeto de la consulta del cursor debe ser compartida con que para rellenar un objeto unico en la rutina de Carga.
ahora Tenemos una clase que nos permite navegar a traves de un conjunto de objetos del dominio del problema, y hemos ampliado nuestra gestion de datos de clase para apoyar a estas operaciones. Lo que aun no hemos hecho es definir como los diferentes conjuntos de objetos debe ser definido. Despues de todo, hay muchos tipos diferentes de conjuntos de objetos de nuestra aplicacion podria requerir que podamos necesitar el conjunto de clientes que han pedido un determinado elemento de serie, tendriamos el conjunto de clientes llamado 'SMITH' o que podamos necesitar el conjunto de todos los clientes (a efectos de notificacion). Una manera obvia de definir estos conjuntos diferentes que podriamos necesitar es definir personalizado de constructores. El listado 3 muestra la interfaz publica de un ejemplo TCustomerList que administra un conjunto de clientes. Tambien vera que se expone una propiedad del Cliente esto simplemente devuelve el CurrentObject estaticamente encasillado a un TCustomer (sabemos y esperamos que todos los objetos en la lista de este tipo por lo que es una operacion segura y evita la colocacion de las encasilladas dentro de la aplicacion principal de la logica). Algunos ultra-purista OO defensores puede afirmar que, mas que el uso personalizado de los constructores de una clase de la jerarquia deben ser creados, con una nueva clase para cada tipo de lista que se requiere. Personalmente puedo ver muy poco beneficio en este enfoque, a menos que el conjunto particular de objetos requiere algunos que se ocupan especialmente de manejo que debe permanecer privada para una lista especifica de aplicacion, y este enfoque tiene la desventaja de requerir una considerable cantidad de codigo escrito y la consecuente clase proliferacion.
ahora podemos lidiar con las listas de clientes, simplemente mediante la creacion de una TCustomerList de la manera mas adecuada. Nuestra aplicacion de codigo podria ser algo como esto:
var
& nbsp & nbsp CustomerList: TCustomerList
begin
& nbsp & nbsp CustomerList := TCustomerList.CreateByName ('SMITH')
& nbsp & nbsp probar
& nbsp & nbsp & nbsp & nbsp CustomerList.Primera
& nbsp & nbsp & nbsp & nbsp mientras no CustomerList.IsLast empiezan
& nbsp & nbsp & nbsp & nbsp & nbsp & nbsp // Hacer algo con CustomerList.Objeto del cliente
& nbsp & nbsp & nbsp & nbsp & nbsp & nbsp CustomerList.Siguiente
& nbsp & nbsp & nbsp & nbsp final
& nbsp & nbsp finalmente
& nbsp & nbsp & nbsp & nbsp CustomerList.Libre
& nbsp & nbsp final
fin
Tener este tipo de dentro de la logica de la aplicacion es mucho mas clara que el equivalente a los procedimientos de construccion de la base de datos de consultas especificas y el uso de los campos directamente. En particular, hemos encapsulado todos estos detalles dentro de nuestra gestion de datos de la clase y este codigo centralizacion permite el lujo de saber que las oportunidades para hacer referencia a una tabla no valida o nombre de campo se reducen considerablemente.
hasta el momento no hemos especificado la implementacion real de la costumbre de constructores en nuestra gestion de la lista de objetos. Como ya se ha señalado, estas clases sentarse resueltamente dentro de nuestra aplicacion de la logica de negocio y por lo tanto debe ser enteramente base de datos independiente. Especificamente, estos constructores no pueden estar involucrados con la construccion de consultas SQL o similares. Estos detalles estan dentro de las atribuciones de la funcion de nuestros datos de gestion de la clase, y asi el correspondiente TDMObject para cada clase va a adquirir la costumbre de constructores, cada uno se corresponde exactamente con el nombre y los parametros para la TPDList objeto para el que es responsable. El proximo mes vamos a redondear este manejo analizando algunos de los detalles de implementacion, y mostrando como las mejoras en nuestra clase de diseño, y el poder de polimorfismo, conduce a un muy reducido escritura de codigo de nuestra aplicacion personalizada clases.
Este articulo la pregunta
Ser capaz de manejar conjuntos de objetos es el bloque de construccion para el manejo de relaciones de objeto. ¿Como podemos utilizarlos para apoyar 1-muchas relaciones como Cliente.Ordenes, y podemos apoyar estas construcciones, genericamente, de la misma manera en que lo hicimos para el 1-1 y muchos-1 relaciones?
((( Listado 1 - Matriz basada en TPDList interfaz)))
tipo
& nbsp & nbsp TPDList = clase
& nbsp & nbsp publica
& nbsp & nbsp & nbsp & nbsp propiedad ObjectAtIndex[Index: Integer]: TPDObject predeterminado
& nbsp & nbsp & nbsp & nbsp propiedad Count: Integer
& nbsp & nbsp final
((( Fin del Listado 1 )))
((( Listado 2 - Navegacion TPDList interfaz)))
tipo
& nbsp & nbsp TPDList = clase
& nbsp & nbsp publica
& nbsp & nbsp & nbsp & nbsp procedimiento
& nbsp & nbsp & nbsp & nbsp procedimiento Siguiente
& nbsp & nbsp & nbsp & nbsp propiedad CurrentObject: TPDObject
& nbsp & nbsp & nbsp & nbsp propiedad IsLast: Boolean
& nbsp & nbsp final
((( Fin del Listado 2 )))
((( Listado 3 - Ejemplo TCustomerList interfaz publica)))
tipo
& nbsp & nbsp TCustomerList = clase (TPDList)
& nbsp & nbsp privada
& nbsp & nbsp & nbsp & nbsp // Resultado := TCustomer (CurrentObject)
& nbsp & nbsp & nbsp & nbsp funcion GetCustomer: TCustomer
& nbsp & nbsp publica
& nbsp & nbsp & nbsp & nbsp constructor CreateAll
& nbsp & nbsp & nbsp & nbsp constructor CreateByName (const Nombre: String)
& nbsp & nbsp & nbsp & nbsp constructor CreateByStockOrder (Elemento: TStockItem)
& nbsp & nbsp & nbsp & nbsp propiedad del Cliente: TCustomer leer GetCustomer
& nbsp & nbsp final
((( Fin del Listado 3 )))
el Siguiente en la serie