El diseño impulsado por seis áreas - el ciclo de vida de los objetos de dominio

Dominio Driven Design - objeto del ciclo de vida

Cada objeto tiene un ciclo de vida, que se muestra en la Figura 6-1. Dado que se crea el objeto, puede experimentar una variedad de diferentes estados, hasta la desaparición final - ya sea archivada o eliminada. Por supuesto, muchos objetos son objetos simples temporales, sólo se crea llamando al constructor, que hacer algunos cálculos, y luego recuperados por el recolector de basura. Tales objetos no tienen que hacerlo tan complicado. Sin embargo, algunos objetos tienen un ciclo de vida más largo, que no es parte del tiempo invertido en la memoria activa. Tienen complejas interdependencias con otros objetos. Ellos experimentan algún cambio de estado en el momento del cambio de cumplir con algunas reglas fijas. Se enfrentan a muchos desafíos en la gestión de estos objetos, el más mínimo error se desviarán diseño de la vía dirigida por modelos.

Figura 6-1

El principal desafío en las siguientes categorías.

(1) el mantenimiento de la integridad de todo el ciclo de vida.

(2) impedir que el modelo de la complejidad de la gestión del ciclo de vida con problemas causados ​​por ellos.

AGGREGATE para (polimerización), que está claramente definida por los límites y afiliaciones, y para evitar confusiones, la intrincada red de objetos para lograr modelo cohesivo. modo de agregación tiene un papel crucial en el mantenimiento de la integridad de las diferentes etapas del ciclo de vida. Nos dirigimos nuestra atención al principio del ciclo de vida, el uso de fábrica (fábrica) para crear y reconstruir los objetos complejos y Agregada (polimerización), para encapsular su estructura interna. Por último, el repositorio (repositorio) en el medio y al final del ciclo de vida para proporcionar búsqueda y recuperación de objetos persistentes y medios de embalaje una gran infraestructura.

A pesar del repositorio y la propia fábrica no se deriva del campo, sino que también juegan un papel importante en el campo del diseño. Estas estructuras proporcionan fácil de agarrar un enfoque de modelo de objeto, el diseño del modelo-DRIVEN más completa.

TOTAL utilizando el modelado, utilizando GUARDAMUEBLES FÁBRICA e incorporado en el diseño, por lo que podemos modelar todo el ciclo de vida del objeto con el fin de detectar la celda, manipulan el sistema. Agregado puede ser dividido en una serie de elementos de modelo dentro de este rango en todas las etapas del ciclo de vida debería conservar sus reglas fijas. FÁBRICA y Repositorio TOTAL operan sobre la base del ciclo de vida particular del complejo convertida encapsulado.

AGREGAR

Reducir el diseño relacionado ayuda a simplificar la travesía entre objetos, y hasta cierto punto limitar la relación del incremento agudo. Pero la mayoría de las áreas de negocio en los objetos tienen una relación muy compleja que en última instancia conducir a una trayectoria de referencia objeto largo y profundo, tenemos que realizar un seguimiento de objetos en este camino. En parte, esto refleja la confusión del mundo real, el mundo real, porque muy pocos límites claros. Pero es una cuestión importante en el diseño de software.

Supongamos que quitar un objeto Person de la base de datos. El nombre de la persona, fecha de nacimiento y la descripción de los puestos se van a eliminar por completo, pero a la dirección de cómo tratar con él? Puede haber otras personas que viven en la misma dirección. Si elimina la dirección, esos objetos persona va a ser una referencia al objeto que desea eliminar. Si deja la dirección, la dirección de la basura se acumula en la base de datos. Aunque automática de basura recogida de basura puede tratar, pero esto es sólo una técnica de reparación, incluso si la existencia de tal sistema de base de datos mecanismo de manipulación, un problema básico de modelado permanece ignorado.

Incluso cuando se considera la transacción huérfanos, un típico modelo de objetos redes también hacen que sea difícil determinar cuál es el impacto potencial producirá una modificación. El hecho de que existe una dependencia de cada objeto de la actualización del sistema, esto es poco realista.

En el sistema de múltiples clientes el acceso simultáneo al mismo objeto, el problema es más prominente. Mientras que muchos de los objetos en el usuario del sistema de consulta y actualización, hay que evitar que se modifican también los objetos interdependientes. Error de área dará lugar a consecuencias graves.

En los modelos con asociación compleja, con el fin de garantizar la coherencia de la cambio de objeto es muy difícil. No sólo los objetos no relacionados deben cumplir con algunas reglas fijas, y cada grupo de objetos estrechamente relacionados deben seguir unas reglas fijas. Sin embargo, el mecanismo de bloqueo excesivamente prudentes sin sentido dará lugar a la interferencia mutua entre múltiples usuarios, haciendo que el sistema inutilizable.

En otras palabras, ¿cómo sabemos un objeto por otros objetos de por dónde empezar y dónde terminar? transacción En cualquier sistema con un almacén de datos persistente, los datos pueden ser modificados debe tener rango, pero tiene que haber una manera de mantener la consistencia de datos (es decir, para mantener los datos sujetos a reglas fijas). Es compatible con una variedad de mecanismo de bloqueo de la base de datos, y puede escribir algunas pruebas para verificar. Pero estas soluciones especiales distraen la atención del modelo, y pronto la gente va a volver a la "paso a paso", el antiguo camino hacia arriba.

De hecho, con el fin de encontrar una solución equilibrada a los diferentes problemas, se requiere un profundo conocimiento del campo, por ejemplo, para comprender los factores profundos tales como cambios en la frecuencia entre el caso particular de la clase. Tenemos que encontrar un conflicto entre los objetos para que menos reglas fijas más estrechamente vinculados modelo.

Aunque la superficie de este problema es una base de datos técnicos asuntos problema, sino que tiene sus raíces en el modelo, en el análisis final es debido a la falta de límites modelo claramente definido. Soluciones derivadas del modelo modelarán más fácil de entender y hacer el diseño más fácil comunicarse. Cuando se modifica el modelo, que nos llevará a hacer cambios para lograr.

En primer lugar, tenemos que hacer referencia a un modelo abstracto del paquete. TOTAL es una colección de objetos relacionados, se utiliza como unidad de modificación de datos. Cada agregado tiene una raíz (root) y un borde (frontera). define de contorno del agregado interna tienen nada. Raíz es una entidad particular agregado incluido. Para el agregado, el objeto externo de referencia sólo puede ser la raíz, y entre los objetos puede referirse unos a otros dentro de los límites. Entidad distinta de la raíz tiene una identidad local, pero que necesitan sólo para identificar sólo distinguirse dentro del agregado, debido a que el objeto externo, excepto la entidad raíz ver otros objetos.

Auto software de taller de reparación podría utilizar el modelo del coche. La Figura 6-2. ENTIDAD es un coche con una identidad global: tenemos que separar este coche con todas las otras áreas de automóviles de todo el mundo (incluso algunos coches muy similares). Podemos utilizar el número de identificación del vehículo para distinguir, número de identificación del vehículo es un identificador único se asigna al nuevo coche. Es posible que desee girar para seguir la historia de los neumáticos Ge por cuatro ruedas bits. Es posible que desee saber el kilometraje y el desgaste de cada neumático. Para saber qué tipo de neumático en donde, el neumático debe ser marcado como ENTIDAD. Cuando el coche fuera de contexto, es probable que no se preocupan por la identidad de estos neumáticos. Si se ha sustituido las llantas y los neumáticos usados ​​a plantas de reciclaje, entonces ya no necesitará el software para realizar un seguimiento de ellos, van a formar parte de una pila de llantas de desecho. Nadie se preocupa por su historia rotación. Más importante, incluso si el neumático está seguro en el coche, nadie consultaría un neumático específico a través del sistema, a continuación, echar un vistazo a este neumático en el que los coches. La gente va a encontrar el coche en la base de datos, y luego mirar la situación de los neumáticos temporal este coche. Por lo tanto, el coche queda agregado entidad raíz, mientras que el neumático está dentro de los límites del agregado esto. Por otra parte, sobre el bloque del motor están grabados con un número de serie, y son independientes coche a veces siendo rastreado. En algunas aplicaciones, el motor puede ser la raíz de su agregado.

reglas fijas (invariables) se refiere a las reglas de consistencia que deben ser mantenidos cuando cambian los datos, se refiere a la relación interna entre los miembros de agregado. Y no serán requeridos a través de cualquier regla de TOTAL en todo momento hasta la fecha. Por el procesamiento de eventos, por lotes, o de otros mecanismos de actualización, que dependen será resuelta dentro de un cierto período de tiempo. Sin embargo, cuando se completa cada transacción, el agregado interno regla fija aplicada se deben cumplir, se muestra en la Figura 6-3.

Ahora, con el fin de lograr agregados sobre este concepto, tenemos que aplicar un conjunto de reglas para todas las transacciones.

raíces entidad con una identidad global, que es en última instancia responsable de comprobar las reglas fijas.

raíz entidad que tenga identidad global. ENTIDAD dentro de los límites con la identidad local, que es la única identidad sólo en el interior de agregado.

objeto externo agregado no puede hacer referencia a ningún objeto dentro de la entidad externa de la raíz. ENTIDAD ENTIDAD puede raíz para referencia interna pasó a ellos, pero estos objetos son sólo para uso temporal de estas referencias, las referencias no pueden ser mantenidas. Raíz puede copiar un objeto de valor pasado a otro objeto sin tener que preocuparse acerca de qué cambios que suceda, porque es sólo un VALOR, ya no tienen ninguna conexión con el agregado.

Como corolario de la regla anterior, sólo root TOTAL con el fin de obtener acceso directo a través de la base de datos. Todos los demás objetos deben ser encontrados por la que atraviesa la asociación.

Los objetos pueden ser mantenidos dentro de las referencias se agregan para otras raíces agregado.

Figura 6-3

operación de eliminación debe eliminar todos los objetos dentro de los límites agregado. (Uso mecanismo de recolección de basura, es muy fácil de hacer debido a otros objetos que no sean la raíz hay referencias externas, por lo que después de eliminar la raíz, se recuperarán otros objetos.)

Al presentar modificaciones a cualquier fronteras interiores objeto agregado, se deben cumplir reglas fijas a través de todo el agregado.

Entidad y objeto de valor que deberíamos reunido diferentes categorías agregadas y definir los límites de cada agregado. En cada agregado, seleccione la entidad como una raíz, y los controles de acceso a todos los demás objetos dentro de un límite a través de la raíz. Sólo objeto externo mantiene una referencia a la raíz. referencia temporal para el elemento interior se puede pasar, pero sólo es válido en una sola operación. Debido a que el control de acceso de la raíz, y por lo tanto no pueden derivación a modificar el objeto interno. Este diseño ayuda a asegurar que los objetos reglas satisface agregar todos los fijos también puede asegurar que cualquier cambio global del Estado en su conjunto para cumplir con las reglas fijas.

No se puede declarar un agregado marco técnico es útil, por lo que se puede implementar mecanismos de cierre automático y otras características. Sin ese marco la tecnología, el equipo debe confiar en la autodisciplina para el uso acordado previamente CONJUNTO, y de acuerdo con estos AGGREGATE para escribir código.

Ejemplos de la integridad de las órdenes de compra

Una vista típica orden de compra (Purchase Order, PO), que se descompone en elementos de adquisición (elemento de línea), una regla fija es el total de elementos de compra no puede exceder el límite de la PO total. La implementación actual de los siguientes tres cuestiones relacionadas entre sí.

Realización (1) de la regla fija. Al agregar un nuevo artículo en su compra, verificación total del PO si el nuevo término para una compra total excede el límite, el PO marcado como no válido. Como veremos, este mecanismo de protección no es suficiente.

(2) la gestión del cambio. Cuando se elimina o se archiva el PO, cada artículos de compra también será un proceso, pero no se dio por un modelo en el que la relación debe parar. Cambiar partes (parte) afectan a los precios en diferentes momentos producido no es clara.

(3) el intercambio de base de datos. serán llevados problemas de base de datos causados ​​por el uso de una pluralidad de usuarios.

La pluralidad de usuarios para acceder y actualizar cada PO al mismo tiempo, se debe evitar que interfieran entre sí. Empecemos con una estrategia muy simple, cuando un usuario inicia la edición de cualquier objeto, el objeto está bloqueado hasta que el usuario confirma la transacción. Por lo tanto, cuando George edición de elemento de adquisición 001, Amanda no puede acceder a él. Amanda puede editar cualquier compra otros artículos en el PO (incluyendo otros artículos a adquirir en PO George se está editando)

Cada usuario se lee desde los objetos de la base, y una instancia de un objeto en su propio espacio de memoria, a continuación, ver y editar el objeto allí. Sólo cuando se inicia la edición, las solicitudes de base de datos serán bloqueados. Por lo tanto, George y Amanda pueden trabajar al mismo tiempo, siempre y cuando no editan simultáneamente el mismo elemento para la compra. Todo es normal, hasta que empiece a editar un artículo en diferentes George y Amanda de compra sobre el mismo PO.

Desde la perspectiva de los usuarios y sus respectivos puntos de vista del software, sus operaciones no son un problema, porque ignoran el resto de los cambios de base de datos durante ocurrió la transacción, y cada usuario no puede modificar bloqueado comprar otros artículos. Cuando dos usuarios guardar los cambios, la base de datos se almacenan en un modelo de dominio PO fijo violar las reglas. Una regla importante de los negocios se destruye, pero nadie sabe

Obviamente, el bloqueo de una sola fila no es un mecanismo de protección adecuada. Si un bloqueo de una orden de compra, puede evitar este tipo de problemas

Hasta Amanda resolver este problema, no se permitirá que el programa para guardar la transacción, Amanda puede resolver este problema mediante el aumento de la cuota o reducir una guitarra. Este mecanismo evita el problema si la mayor parte del trabajo se extendió a través de múltiples PO, entonces esto puede ser una buena solución. Pero si una gran cantidad de personas al mismo tiempo en diversos artículos eran una gran operación PO, este mecanismo de bloqueo se vuelve muy incómodo.

Incluso muchos pequeños PO, hay otros medios para sabotear estas reglas fijas. Vamos a ver "Parte". Si el trombón cuando Amanda a la orden y alguien cambió el trombón precio, que no destruirá las reglas fijas?

Además hemos tratado de bloquear toda la adición PO, también se bloqueará parte, el caso cuando George, Amanda y Sam trabajar en diferentes PO va a suceder.

El trabajo se ha vuelto más y más problemático, porque ha habido muchos casos de disputa en la primera parte. Tales resultados se producirían en la figura 6-10: 3 individuos necesitan esperar.

Ahora podemos empezar a mejorar el modelo añadiendo el siguiente conocimiento del negocio en el modelo.

(1) Número de pieza en el PO (generar alta competencia).

(2) Parte de la PO modificado es menos de las modificaciones.

(3) Los cambios en el precio (el precio) no está necesariamente extenderse a un PO existente, PO modificar el precio dependiendo de qué estado.

Cuando se considera que haya sido entregada y archivados PO, el tercer punto es particularmente evidente. Muestran, por supuesto, es el precio al que llenar, más que el precio actual.

Implementar este modelo puede garantizar que las normas resultantes PO fijos y elementos relacionados con la adquisición, mientras que el precio de las piezas modificadas no afectará inmediatamente la adquisición de artículos componentes referenciados. Regla implica una más amplia se puede cumplir por otros medios. Por ejemplo, el sistema puede comprar artículos enumerados para el usuario todos los días expiró el precio, por lo que los usuarios pueden decidir si se debe actualizar o eliminar artículos de la compra. Pero esto no debe permanecer reglas fijas. Al reducir la dependencia de parte de elementos de adquisición, la contención evitar, y para reflejar mejor las realidades del negocio. Al mismo tiempo, fortalecer la relación entre las posiciones de pedido de compra y para asegurar el cumplimiento de esta importante reglas de negocio.

TOTAL obligó a la empresa de acuerdo con sus respectivas relaciones entre el PO y los elementos reales de compra. PO y crear artículos de la compra y elimine se vincula naturalmente, y crear y eliminar parte de la misma es independiente.

TOTAL divide en una serie, en este rango, cada etapa del ciclo de vida debe cumplir con ciertas reglas fijas. modos de fábrica repositorio y que se discute a continuación se describen las operaciones realizadas en el agregado, se convierten a la complejidad del ciclo de vida de un paquete en particular, junto ......

comprensión personal: no entendía por completo, parece que el problema de los recursos de procesamiento de modelado de la competencia.

FÁBRICA

Cuando se crea un objeto o agregado para crear un todo, si el trabajo es crear complejas o demasiado expuesta estructura interna, que puede ser utilizado para la fábrica de encapsulación.

La función principal del objeto se refleja en sus aspectos internos complejos y se asocia con Ge. Deberíamos haber sido objeto de refinación, hasta que todo su significado o función en la interacción de contenido relacionado se elimina por completo hasta ahora. Un objeto en su ciclo de vida a tener mucha responsabilidad. Si deja que un objeto complejo es responsable de su creación, la sobrecarga de rol causará problemas.

Motor de automóvil es un dispositivos mecánicos complejos Ge, que consiste de partes docenas trabajar juntos para realizar sus funciones del motor - el eje se hace girar. Podemos tratar de diseñar un conjunto de motor y deje que arrastrarse embute en un conjunto de pistones y cilindros, bujías también pueden encontrar el gato y poner su propio toque a sí mismo en ella. Sin embargo, la complejidad de la máquina de montaje de un tipo puede no ser tan confiable o eficiente nuestro motor común. En cambio, usamos otras cosas para montar el motor. Tal vez los robots mecánicos o industriales. Si se trata de un robot o humano, de hecho, que los dos para ser montados complejo motor. Asamblea partes trabajan y el trabajo hace girar el eje completamente ajenos. Sólo necesito más en forma cuando el coche de producción no necesita un robot o un mecánico cuando conducimos. A medida que el coche de montaje y el conductor nunca ocurrirá simultáneamente, y por lo tanto, estas dos funciones en un único mecanismo no tiene valor. Del mismo modo, el trabajo de montaje de objetos compuestos complejos también se separa preferiblemente del objeto de trabajo a ser ejecutado.

A medida que la interfaz debe implementar el paquete de objetos en el mismo (de modo que los clientes no conocen el mecanismo de trabajo de los objetos se puede utilizar la función de objeto), FÁBRICA encapsula el conocimiento necesario para crear objetos complejos o agregado. Proporciona una interfaz para reflejar los objetivos del cliente, así como una visión abstracta del objeto que se creará.

Responsabilidad debe crear instancia de objeto complejo y el agregado transfiere a un objeto separado, que en sí mismo puede no tomar la responsabilidad en el modelo de dominio, pero todavía es parte del campo del diseño. Un conjunto complejo que encapsula todo el interfaz operaciones, y esta interfaz no requiere que el cliente objeto de la clase específica de referencia se crea una instancia. Al crear TOTAL tomarlo como un todo, y para asegurar que cumpla con reglas fijas.

FÁBRICA Hay muchos diseño. [Gamma et al.1995] discute en detalle el modo de varios creación propósito específico, que comprende FÁBRICA METHOD (método de fábrica), Abstract Factory (fábrica abstracto), y el constructor (constructor). El libro estudia el modo para la mayoría de los problemas de construcción de objetos complejos. El enfoque de este libro no es la discusión en profundidad de las cuestiones de diseño de fábrica, pero para mostrar la posición de FÁBRICA importante - es un componente clave del campo del diseño. FÁBRICA ayuda a asegurar el correcto uso del diseño basado en modelos adelante por el camino correcto.

Cualquier fábricas buenas deben cumplir dos requisitos básicos

(1) se crea para cada método átomo, pero también para asegurar que todos los objetos creados o reglas de agregado fijos. FÁBRICA generado objeto de estar en un estado coherente. Al generar ENTIDAD, esto significa crear un conocer toda TOTAL todas las reglas fijas, pero se puede añadir un elemento opcional para la polimerización después de la creación. Cuando se crea un objeto de valor constante, lo que significa que todas las propiedades se deben inicializar al estado final correcta. Si FÁBRICA su interfaz ha recibido una solicitud de creación de un objeto, pero no puede crear correctamente el objeto, entonces se debe lanzar una excepción, u otros mecanismos para asegurar que el error no vuelve a un valor medio.

(2) fábrica debe ser abstraído al tipo deseado, en lugar de clases específicas que se crearon. Modo [Gamma et al.1995] avanzada fábrica de introducción al tema

comprensión personal: entiendo, la creación de un objeto si es muy compleja (o inicializado para montar una gran cantidad de parámetros, ciertas reglas) que puede utilizar el patrón de la fábrica, los desarrolladores de tecnología debe ser muy consciente de la fábrica modelo, la empresa no necesita saber cuál es el modelo de fábrica.

Resumen: no entendía, prestar más atención a esta parte de la base de datos de objetos de programa y diseño, no es el modelo de ciclo de vida, un aspecto bueno en los patrones de diseño y paradigma de diseño de base de datos debería ser suficiente.

Supongo que te gusta

Origin www.cnblogs.com/zhijiancanxue/p/12538475.html
Recomendado
Clasificación