Cómo diseñar Data Transfer Objects en la capa de lógica de negocios

Question

DTO

Estoy construyendo una aplicación web me gustaría escalar a muchos usuarios. Además, tengo que exponer la funcionalidad de los terceros de confianza a través de servicios web.

Estoy usando LLBLGen para generar la capa de acceso de datos (utilizando SQL Server 2008). El objetivo es construir una capa de lógica de negocio que protege a la aplicación web de los detalles de DAL y, por supuesto, para proporcionar un nivel adicional de validación más allá de la DAL. Además, en la medida de lo que puedo decir en este momento, el servicio web será esencialmente una envoltura delgada sobre la BLL.

El DAL, por supuesto, tiene su propio conjunto de objetos de entidad, por ejemplo, CustomerEntity, ProductEntity, y así sucesivamente. Sin embargo, no quiero que la capa de presentación para tener acceso a estos objetos directamente, ya que contienen métodos específicos DAL y el conjunto es específico para el DAL y así sucesivamente. Por lo tanto, la idea es crear objetos de transferencia de datos (DTO). La idea es que estos serán, en esencia, el viejo y simple C # /. Objetos NET que tienen todos los campos de, por ejemplo, un CustomerEntity que son en realidad el cliente tabla de base de datos pero ninguna de las otras cosas, excepto tal vez algunas propiedades IsChanged / IsDirty. Por lo tanto, no habría CustomerDTO, ProductDTO, etc. Asumo éstos heredar de una clase DTO base. Creo que puedo generar estos con alguna plantilla para LLBLGen, pero no estoy seguro de ello todavía.

Por lo tanto, la idea es que el BLL expondrá su funcionalidad mediante la aceptación y devolución de estos objetos DTO. Creo que el servicio web se encargará de convertir estos objetos a XML para los terceros usarlo, muchos pueden no estar usando .NET (también, algunas cosas serán guión que puede llamarse desde llamadas AJAX en la aplicación web, utilizando JSON).

No estoy seguro de la mejor manera de diseñar este y exactamente cómo seguir adelante. Estos son algunos asuntos:

1) ¿Cómo debe ser expuesto a los clientes (La capa de presentación y el código de servicio Web)

Yo estaba pensando que no habría una clase pública que tiene estos métodos, cada llamada sería ser una operación atómica:

InsertDTO, UpdateDTO, DeleteDTO, GetProducts, GetProductByCustomer, y así sucesivamente ...

A continuación, los clientes se acaba de llamar a estos métodos y pase los argumentos adecuados, típicamente un DTO.

Es este un buen enfoque viable?

2) Lo que hay que volver a partir de estos métodos? Obviamente, el Get / Fetch tipo de métodos volverá DTO. Pero ¿qué pasa con inserciones? Parte de la firma podría ser:

InsertDTO(DTO dto)

Sin embargo, cuando se inserta lo que debería ser devuelto? Quiero ser notificado de errores. Sin embargo, yo uso las claves principales autoincremental para algunas tablas (Sin embargo, algunas mesas tienen teclas naturales, sobre todo muchos-a-muchos otros).

Una de las opciones que pensaba era en una clase Resultado:

class Result
{
    public Exception Error {get; set;}
    public DTO AffectedObject {get; set;}
}

Por lo tanto, en un inserto, el DTO conseguiría su identificación consigue (como CustomerDTO.CustomerID) conjunto de propiedades y luego poner en este objeto de resultado. El cliente sabrá si hay un error si Result.Error! = Null y entonces sería conocer el ID de la propiedad Result.AffectedObject.

Es este un buen enfoque? Un problema es que parece que está pasando una gran cantidad de datos de ida y vuelta que es redundante (cuando es sólo el ID). No creo que la adición de una propiedad "int NewID" sería limpia debido a que algunos insertos no tendrán una clave autoincremental así. Otra cuestión es que no creo que los Servicios Web se ocuparía de este pozo? Creo que simplemente devolver el DTO base para AffectedObject en la clase de resultados, en lugar de la DTO derivada. Supongo que podría resolver esto por tener un montón de los diferentes tipos de objetos de Resultados (quizás derivadas de un resultado base y heredar la propiedad de errores), pero que no parece muy limpio.

Muy bien, espero que esto no es demasiado prolijo pero quiero ser claro.

Answer 1

1: Ese es un enfoque bastante estándar, que se presta bien a una aplicación "depósito" para el mejor enfoque de unidad comprobable

.

2: Excepciones (que debe ser declarado como "fallos" en el límite de WCF, por cierto) conseguirán planteado de forma automática. No es necesario para manejar eso directamente. Para los datos - hay tres enfoques comunes:

• ref uso en el contrato (no muy bonita)
• devolver el objeto (actualizado) - es decir public DTO SomeOperation(DTO item);
• retorno sólo la información de identidad actualizado (-clave primaria / marca de tiempo / etc)

Una cosa acerca de todo esto es que no requiere un tipo diferente por operación (contraste de su clase Result, que tendría que ser duplicado por DTO).

Answer 2

P1: Se puede pensar en los tipos de compuestos WCF contrato de datos como DTO para resolver este problema. De esta manera la capa de interfaz de usuario sólo tiene acceso a DataMember del DataContract. Sus operaciones atómicas serían los métodos expuestos por su interfaz WCF.

P2:. Configure sus contratos de datos de respuesta para devolver un nuevo tipo personalizado con sus claves primarias, etc ... WCF también se puede configurar para excepciones de burbujas de nuevo a la interfaz de usuario