proyectos proyecto net mvc5 mvc asp anexsoft asp.net n-tier dto project-structure

asp.net - net - ¿Qué capa de proyecto debería Screen DTO Live In?



proyecto mvc5 (2)

¿Estás usando servicios reales (web o WCF)? De ser así, defina los DTO en la capa de servicio y el proxy creado al agregar un servicio (o web si usa ASMX antiguo) de referencia contendrá todos los tipos de DTO. Esta es la forma más sencilla de hacerlo y mantiene solo un acoplamiento flexible entre su proyecto ASP.NET y su proyecto de servicio; no se requiere referencia directa del proyecto en ninguna dirección. A medida que actualiza sus DTO, todo lo que necesita hacer es actualizar su referencia de servicio y expondrá automáticamente las actualizaciones a su proyecto web a través de la clase proxy que se genera.

En cualquier caso, si está siguiendo algo como un enfoque DDD, es mejor que sus proyectos de infraestructura (como una IU específica de la plataforma web) hagan referencia a los objetos de su dominio, y viceversa. Si sigues mi consejo anterior, sin embargo, tu proyecto web no tendrá una dependencia directa del proyecto en absoluto, lo cual es algo bueno, y ciertamente mejor que tener tus objetos de dominio enriquecido dependiendo de tu proyecto web (si eso fuera incluso una consideración - me doy cuenta de que no estabas diciendo que estabas haciendo esto).

Si sus DTO son específicos de la vista, los incluiría en su proyecto de IU. Realmente debería ser tarea del controlador asegurarse de que la Vista solo obtenga del Modelo lo que necesita, en su caso un objeto de valor con solo los campos que necesita la vista.

Tengo un proyecto en el que utilizamos pantallas DTO para encapsular los datos entre la capa de servicio y la capa de presentación . En nuestro caso, la capa de presentación es ASP.Net.

Las únicas clases que conocen acerca de los DTO son las clases de capa de servicio y las páginas / controles que llaman a estos servicios y muestran los DTO.

Los DTO casi siempre son específicos de Page / Control, así que creo que pertenecen a la capa de presentación, pero eso significaría que la capa de servicio tendría que hacer referencia a la capa de presentación para poder usar los DTO.

Casi estoy pensando que la Capa de Servicio debería devolver objetos más ricos (pero no entidades de dominio) y luego la Capa de Presentación puede tomar estos objetos y asignarlos a DTO muy específicos para cada preocupación de Página / Control.

Aquí hay una declaración de interfaz y un DTO para que pueda ver de lo que estoy hablando:

public interface IBlogTasks { BlogPostDisplayDTO GetBlogEntryByTitleAndDate(int year, int month, string urlFriendlyTitle); } public class BlogPostDisplayDTO { public string Title { get; set; } public DateTime PostDate { get; set; } public string HtmlContent { get; set; } public string ImageUrl { get; set; } public string Author { get; set; } public int CommentCount { get; set; } public string Permalink { get; set; } }

Editar

Aquí hay otro ejemplo de código para describir un caso de uso donde el modelo de dominio no está involucrado. Tal vez esto aclarará las cosas un poco. Creo que he sobrecargado el significado de DTO. No estoy hablando de un DTO para la función de transferir un objeto por el cable. Estoy creando DTO para formalizar contratos entre la comunicación a mi capa de servicio.

public interface IAuthenticationTasks { bool AuthenticateUser(AuthenticationFormDTO authDTO); } public class AuthenticationFormDTO { public string UserName { get; set; } public string Password { get; set; } public bool persistLogin { get; set; } }

Digamos que mi autenticación de repente requiere un parámetro de dirección IP. Ahora puedo agregar esa propiedad al DTO sin tener que cambiar mi interfaz de contrato.

No quiero pasar entidades a mi capa de presentación. No quiero que mi código tenga la capacidad de ir a BlogPost.AddComment(new Comment())


Incluso el caso de uso canónico para el ''DTO'' es más un objeto serializable que se puede pasar por el cable, en este caso realmente se está refiriendo más a ''objetos de transferencia de presentación'' o ''modelos de vista''.

Normalmente, para nuestros proyectos la respuesta a dónde viven estos es dónde está el código de ''traducción'' que mapea el modelo de dominio DDD a las clases de PTO. Si eso está en la capa de Prensenación (quizás una respuesta no tan buena), entonces la presión. capa es donde declararía las PTO. Pero la mayoría de las veces, es el ''Servicio'' que hace la traducción por usted y eso significa que tanto el ''Servicio'' como la ''Presentación'' necesitan referencias a las PTO y que (generalmente) conduce a su declaración en forma separada, proyecto / asamblea / espacio de nombres neutral / lo que tanto la capa de presentación Y la capa de servicio pueden hacer referencia.