Confusión entre las OTD (linq2sql) y objetos de la clase!

Question

he estado trabajando con éxito con linq2sql y los dtos LINQ (las clases que son creados por linq2sql) ....

Estoy confundido, tengo la tarea de actualizar una aplicación antigua y puedo ver que mis dtos serán utilizados cómo deben ser .... para el transporte de la fecha

Estoy utilizando el patrón de repositorio, por lo que estoy pasando datos de un repositorio para el servicio a través de los dtos Linq2Sql ... una vez que estoy en la capa de servicio (esto es básicamente mi lógica de negocio), entonces tengo que pasar alrededor de objetos de clases ..

estos objetos de clase son, básicamente, una imagen de espejo (más o menos) de los dtos - hay algunos cambios en algún lugar, pero en general la misma ..

Así que volviendo a la cuestión en la mano! - ¿Es una buena práctica utilizar dtos únicamente a los datos de transporte desde el repositorio de capa de servicio ... y una vez en la capa de servicio (lógica de negocio) que debería, pero MAPEO todos mis dtos de allí homólogos de objetos de clase (por supuesto usando AutoMapper! !)

Mi otra alternativa es continuar utilizando las DTOS como objetos de clase y pasarlos alrededor de método a método y como tipo de retorno, etc, pero siento que esta es una mala práctica y sigo dando vueltas en círculos preguntándose qué método debo aplicar?

Cualquier ayuda muy apreciada

gracias

Answer 1

Aquí está mi opinión: Cuando se trata de cualquier aplicación no trivial. Usando sus objetos Linq2Sql como su modelo de dominio es una muy mala idea. Veo Linq2Sql como un ORM y nada más. Bases de datos (que Linq2Sql tiene una correspondencia directa a) es una normalización de los datos . Las clases (en el sentido OOAD) son una normalización de comportamiento (no datos).

  

[estos objetos de clase son, básicamente, una imagen de espejo] ...

Me encontré con esto cuando la creación de aplicaciones con Linq2Sql. Vamos a ser realistas .... más aplicaciones de línea de negocio son aplicaciones CRUD glorificados. Por lo tanto, no está fuera de la cuestión de que un gran porcentaje de entidades de su aplicación corresponderá directamente a las tablas de bases de datos. no quería estar vinculado directamente a la DTO que se generaron, pero al mismo tiempo no quería clases duplicadas esparcidos a través de mi aplicación.

Así que aquí está mi solución:
I "programado para una interfaz".

Digamos que tengo un PersonDto (Dto pie para transferencia de datos de objetos) con propiedades de FirstName, LastName, Age (que se relacionan directamente con las columnas de base de datos).

I creado una interfaz IPerson y tenía mi PersonDto ponerlo en práctica.

  [Table(Name="Persons")]
  internal class PersonDto : IPerson
  {
      ....
  }

Y mi método repositorio tardaría en recuperar y IPerson en contraposición a la clase Linq2Sql.

    IPerson somePerson = _repository.Get(someGuid);
    somePerson.FirstName = "SomeName";
    _repository.Save(somePerson);

Este enfoque ha funcionado muy bien para mí. Cada vez que siento la necesidad de desviarse de la DTO, puedo hacerlo con bastante facilidad debido a la interfaz que representa mi objetivo en comparación con el DTO.

Algunas sugerencias generales: Construir sus DTO de la mano ... Sé que suena loco, pero usted encontrará que funciona muy bien con una parte superior hacia abajo, basado en pruebas enfoque de desarrollo. objetos (Linq2Sql) de su DTO serán extremadamente ligero y estarán abiertos a los cambios del diseñador .dbml.

Mantener interno de su DTO y DataContext de. No hay ninguna razón para de ser expuesto públicamente (teniendo en cuenta que usted tiene interfaces públicas para usted repositorios y objetos de dominio) de su dto. Hacer esto forzará una separación lógica entre su modelo de dominio y el acceso a los datos.

Ponga toda su capa de acceso a datos en un proyecto separado (de nuevo para hacer cumplir esta separación).

Ponga sus declaraciones de interfaz en un proyecto independiente (esto asegurará que no se quede en las referencias circulares).

Espero que esto ayude ...

Answer 2

que en realidad tenía una pregunta similar sobre este tema, aunque mi intención era ligeramente diferente. La recomendación fue utilizar las clases Linq2Sql como los objetos de dominio y tomar ventaja de las clases parciales como otros han mencionado. Mi principal preocupación llegó con la forma de los objetos (es decir, nombres de propiedad), y la accesibilidad de los miembros de la clase (es decir, V.S. privada protegida por ejemplo).

La forma de los objetos e incluso la accesibilidad pueden abordarse mediante el uso de plantillas T4, donde Damien Guardia ha reunido una plantilla de T4 para que pueda controlar la forma de las clases que Linq2Sql generaría para usted. Esto se puede ver aquí T4 plantilla para Linq2SQL .

Este es el enfoque que voy a mirar hacia dentro y ver si se ocupa de mis preocupaciones. Además, si su capa de servicios puede aceptar interfaces a los argumentos del método también se puede controlar lo que la capa de servicio tiene acceso a través de la interfaz de envolturas alrededor de su Linq2SQL dtos.

Espero que esto ayude.

Answer 3

Esta es una de las mejores discusiones del tema que he visto:

http://blog.wekeroad.com/ blog / LinqToSql-mamá-dijo-knock-te-out /

Al final, las decisiones de acoplamiento y de cohesión son situacional y usted tiene que decidir lo que es mejor para su situación.

Cuando su aplicación crece más LinqToSql, lo fácil será dar un tirón a cabo LinqToSql e insertar otro ORM en su lugar? Esto es algo que tienes que pensar seriamente en.

En general, reducir al mínimo el conocimiento de su capa de negocio tiene sobre LinqToSql. LinqToSql debe estar completamente oculta a la capa de interfaz de usuario (su capa de negocio hace que una buena parte de este escudo). Es muy fácil ir por el camino equivocado arquitectónico con LinqToSql y puede ser muy difícil volver por el camino correcto después de los hechos.

Answer 4

Las clases generadas por el diseñador linq2sql son las clases parciales, por lo que se puede extender estos y poner su lógica de negocio directamente en ellos. La idea es que LINQ se utiliza para guardar / reconstruir estas entidades para que pueda evitar el tipo de mapeo que estás hablando.