Business Objects - Recipientes o funcionales? [cerrado]

Question

Donde trabajo, hemos ido hacia atrás y hacia adelante sobre este tema varias veces y está buscando una comprobación de validez. Aquí está la pregunta:. En caso de Business Objects ser contenedores de datos (más como DTO) o en caso de que también contienen lógica que puede realizar algunas funciones en ese objeto

Ejemplo - Tome un objeto de cliente, es probable que contenga algunas propiedades comunes (nombre, identificación, etc.), debe ese objeto al cliente también incluir funciones (SAVE, Calc, etc.)

?

Una línea de razonamiento dice separar el objeto de la funcionalidad (principal responsabilidad individual) y poner la funcionalidad en una capa de lógica de negocios o un objeto.

La otra línea de razonamiento dice, no, si tengo un objeto al cliente que sólo quieren llamar Customer.Save y hacerse con él. ¿Por qué necesito saber acerca de cómo guardar un cliente si estoy consumiendo el objeto?

Nuestros dos últimos proyectos han tenido los objetos separados de la funcionalidad, pero el debate se ha planteado de nuevo en un nuevo proyecto. ¿Qué tiene más sentido?

Editar

Estos resultados son muy similares a nuestros debates. Un voto a un lado u otro cambia por completo la dirección. ¿Alguien más desea agregar sus 2 centavos?

Editar

Apesar de la toma de muestras respuesta es pequeña, parece que la mayoría cree que la funcionalidad en un objeto de negocio es aceptable siempre que es simple pero la persistencia es la mejor situada en una clase / capa separada. Vamos a dar a este un intento. Gracias por el aporte de todos ...

Answer 1

Los objetos son del estado y el comportamiento en conjunto. Si un objeto tiene un comportamiento sensible (por ejemplo, calcular la edad de una persona a partir de su fecha de nacimiento, o un impuesto total de una factura), por todos los medios que se suman. Los objetos de negocio que no son nada más que dtos se denominan un "modelo de dominio anémico". No creo que se trata de un requisito de diseño.

La persistencia es un tipo especial de comportamiento. Lo que estoy llamando "sensible" es el comportamiento empresarial. Un objeto de negocio no tiene por qué saber que es persistente. Yo diría que un DAO puede mantener la persistencia separado del comportamiento empresarial. No pongo en "Guardar" en la categoría "sensible".

Answer 2

Objetos del asunto puede tener funcionalidad de negocio .

La persistencia no es una funcionalidad de negocio , pero es la implementación técnica.

Para acortar una larga historia:

1. Guardar / Actualizar / Eliminar / Encuentra etc -. Mantenerse alejado de los objetos de negocio en una capa de persistencia
2. CalculateSalary, ApplyDiscount etc, son los métodos relacionados con la empresa y pueden ser:
   1. métodos de la objetos de negocio (así BO es independiente representación de la entidad) o;
   2. servicios separados implementar la funcionalidad en particular (por lo BOs están actuando más como DTO).

En cuanto al punto 2.
Debo mencionar que el enfoque 2.1 tiende a hacer que la JS demasiado hinchado y violar SRP . Mientras que 2.2 presenta un mayor mantenimiento complejidad .

Por lo general equilibrio en entre el 2,1 y el 2,2 por lo que pongo cosas triviales relacionados con los datos en objetos de negocio y crear servicios para un poco más complejo scenarious (si hay más de 4 líneas de código - hacer que sea un servicio).

Esto cambia el paradigma de Business Objects a ser más Transferencia de objetos de datos en su lugar.

Pero esto todas las marcas proyectan más fácil de desarrollar, probar y mantener.

Answer 3

La respuesta es la misma independientemente de la plataforma o lenguaje. La clave de esta pregunta es si un objeto debe ser capaz de ser autónoma o si es mejor para cualquier comportamiento dado que extenderse entre los objetos con más centrado responsabilidad .

Para cada clase de la respuesta podría ser diferente. Nos encontramos con un espectro largo de la cual podemos colocar las clases basadas en el Densidad de Responsabilidad .

                          (Level of responsibility for behavior)
         Autonomy - - - - - - - - - - - - - - - - - - - Dependence  
      High
  C      -   <<GOD object>>                            <<Spaghetti code>>
  l      -
  a      -  
  s      -                                      
  s      -                 
         -                        
  s      -  
  i      -  
  z      -
  e      -  <<Template>>                                <<Framework>>
       low  

ejemplo de permiten favor dejar la clase realizar todas las conductas en sí, o tantos como sea posible. Comenzando en la parte izquierda de este gráfico, al hacer la clase más autónomo, el tamaño de la clase crecerá menos que refactoriza continuamente para que sea más genérico. Esto conduce a una Plantilla . Si no se realiza una refactorización, la temdency es para la clase para ser más " como un dios " porque si hay algún comportamiento que necesita, tiene un método para eso. El número de campos y métodos crecer y pronto se convierten en tanto incontrolable e inevitable. Puesto que la clase ya hace mucho, los codificadores prefieren añadir a la monstruosidad de tratar a pieza aparte y cortar el nudo gordiano.

El lado derecho de la gráfica tiene clases que dependen de otras clases en un alto grado. Si el nivel de dependencia es alta pero la clase individual es pequeña, esto es un signo de un marco ; cada clase no hace mucho y requiere una gran cantidad de clases dependientes para llevar a cabo alguna función. Por otro lado, una clase altamente dependiente que también tiene una gran cantidad de código es una señal de que la clase está llena de espaguetis .

La clave de esta pregunta es determinar donde se siente más cómodo en el gráfico. En cualquier caso, las clases individuales se terminan propagación a cabo en el gráfico a no ser que se aplica un principio de organización, que es cómo se puede lograr los resultados de Plantilla o Marco .

Tras haber escrito eso, yo diría que hay una correlación entre el tamaño de la clase y el grado de organización. Robert C. Martin (o "Uncle Bob") cubiertas de tierra similar con dependencias de paquetes en su papel muy completo en Principios de diseño y patrones de diseño . JDepend es una implementación de las ideas detrás de la gráfica en la página 26 y complementos herramientas de análisis estático como y href="http://pmd.sourceforge.net/" rel="nofollow noreferrer"> PMD .

Answer 4

creo que tiene más sentido para los negocios objetos que saber "mango" a sí mismos, a continuación, a tener que poner esa carga en otras partes del sistema. En su ejemplo, el lugar más lógico para hacer frente a la manera de "Guardar" datos de los clientes serían, para mí, en el objeto al cliente.

Esto puede ser porque considero que la base de datos para ser el "contenedor de datos", por lo que estoy a favor de los "objetos de negocio" es el nivel más alto que protege el contenedor de datos de acceso directo y hace cumplir las "reglas de negocio" estándar sobre cómo se accede a los datos / manipulado.

Answer 5

Hemos usado marco CSLA de Rocky Lhotka durante años y encanta la forma en que está diseñado. En ese marco toda la funcionalidad está contenida en los objetos. Aunque puedo ver el valor de separting la lógica, yo no creo que cambiaremos lejos de esta filosofía en el corto plazo.

Answer 6

Los objetos de negocio debe ser de encapsular los datos y los comportamientos asociados de la entidad empresarial modelado por ese objeto. Piense en ello como esto: uno de los más importantes principios de la programación orientada a objetos es la encapsulación de datos y comportamientos asociados en esos datos.

Persistencia no es un comportamiento del objeto modelado. Encuentro progresos de desarrollo más fácilmente si los objetos de negocio son ignornant persistencia. Desarrollar nuevo código y pruebas unitarias nuevo código suceda más rápido y más fácil si los objetos de negocio no están específicamente ligados a la instalación de cañerías subyacente. Esto se debe a que pueda burlarse de aquellos aspectos y olvidarse de tener que pasar por el aro para llegar a la base de datos, etc. Mis pruebas unitarias se ejecutarán más rápido (una gran ventaja si usted tiene miles de pruebas automatizadas que se ejecutan con cada generación) y yo tendrá menos estrés, porque no voy a tener pruebas fallan debido a problemas de conexión de base de datos (ideal si usted a menudo trabaja fuera de línea o de forma remota y no siempre se puede tener acceso a su base de datos y oh, por cierto, esos aspectos (conectividad de base de datos, etc.) deben ser probado en otro lugar!).

  

La otra línea de razonamiento dice, no, si tengo un objeto al cliente que sólo quieren llamar Customer.Save y hacerse con él. ¿Por qué necesito saber acerca de cómo guardar un cliente si estoy consumiendo el objeto?

Sabiendo que Customer tiene un método Save ya es saber cómo guardar un objeto de cliente. No ha evitado el problema mediante la incorporación de esa lógica en su objeto de negocio. En su lugar, usted ha hecho su base de código más estrechamente acoplado y por lo tanto más difícil de mantener y de prueba. Empujar la responsabilidad de persistir el objeto a otra persona.

Answer 7

Los objetos de negocio, ya que se nombran, obviamente, debe Coutain su propia lógica de negocio, la dinámica de la lógica de negocio entre el dominio de estar en la capa de servicio.

En el otro lado, podría el BO ser un contenedor de datos (DTO?) Composición y los métodos; significando BO se functionnal pura? Eso podría evitar todas las conversiones entre Bo y DTO.

Answer 8

En una arquitectura MVC,

Se puede decir que el Modelo contiene objetos de negocio.