sharp - programacion de bases de datos con c# pdf

Acomodando un Servicio WCF de la manera correcta

Question

Mi pregunta es más de naturaleza arquitectónica, menos involucrada con la implementación real.

Tengo una API basada en WCF, pero no puedo decidir cómo separar el PL del BL. He reducido mi servicio, por lo que solo tiene un mínimo de implementación, algo así como:

public TagItemResponse TagItem(TagItemRequest request)
{
   return (new ItemTagRequestProcessor()).GetResponse(request);
}

Entonces, por supuesto, surge la primera pregunta, ¿a qué nivel pertenecen los RequestProcessors? Creo que sería un error llamar fachada, pero al mismo tiempo, no tienen nada que ver con la presentación. Por el momento, decidí que, sin embargo, pertenecen a la PL. Los métodos de procesador toman mis DTO''s (DataContracts) como entrada, validan el mensaje de solicitud (clase base), autentican (clase base) y eventualmente devuelven una sola respuesta DTO, así:

protected override void Process(TagItemRequest request, TagItemResponse response, Host host)
{
    var profile = ProfileFacade.GetProfile(host, request.Profile);
    var item = ItemFacade.GetItemId(host, request.Item);
    var tags = new List<Tag>();

    foreach (var name in request.Tags)
    {
        var tag = TagFacade.GetTag(profile, name);
        ItemFacade.TagItem(item, tag);
        tags.Add(tag);
    }

    ItemFacade.UntagItem(item, tags);
}

Ahora me pregunto, ¿por qué necesito las clases de fachada 1: 1 relacionadas con mis objetos comerciales? Por ejemplo, tengo una HostFacade que actúa como una capa entre hostDAO y los procesadores. Sin embargo, tiene muy poca lógica, simplemente maneja las llamadas DAO.

public static Host GetHost(HostDTO dto)
{
   return HostDAO.GetHostByCredentials(dto.Username, dto.Password);
}

Pregunta: también podría fusionar los procesadores y las fachadas, ¿verdad?

He leído muchos artículos / libros sobre el tema, pero todavía no puedo establecerme en el camino "correcto" y tiendo a elegir un enfoque diferente cada vez que enfrento el problema. Me pregunto si existe un enfoque correcto.

Encontré f.ex. el ejemplo doFactory, donde hablaron con las clases DAO directamente desde la implementación del servicio. Realmente no me gusta eso, ya que la mayoría de los métodos de ServiceContract comparten cierta lógica, y por lo tanto se prestan bien para su uso con clases base compartidas.

También encontré otros ejemplos en los que solo se llaman las fachadas desde los servicios, pero parece funcionar bien solo para mensajes muy detallados. Mis mensajes son ''gordos'' y compuestos para reducir al máximo la cantidad de llamadas al servicio. Mi capa de procesamiento adicional parece ser mi verdadero problema.

Probablemente no haya una sola respuesta sobre cómo clasificar correctamente un servicio de WCF, pero espero que haya algunos de ustedes con una opinión que o bien cumpla mis instintos o arroje algo de luz sobre el tema para mí.

Gracias!

Geoffrey

Answer 1

En primer lugar, supongo que, por PL, ¿quiere decir capa de presentación, no capa de persistencia?

Al implementar un diseño de aplicación en capas, la pregunta principal siempre debe ser: ¿puedo reemplazar la implementación de una capa inferior sin afectar la implementación de la (s) capa (s) anterior (es)?

Esto generalmente se ilustra mejor con la capa de persistencia. Si cambia de SQL Server 2008 a MySQL, por ejemplo, la capa de persistencia cambia (por supuesto). Pero, ¿son necesarios los cambios en la capa de negocios? Por ejemplo, ¿la capa empresarial atrapa las instancias de SqlException que solo SqlClient lanza? En un buen diseño, la capa de negocios no necesita cambios en absoluto.

El mismo principio debería aplicarse a la separación entre la capa de negocio y la capa de presentación.

En su ejemplo, diría que el ItemTagRequestProcessor no debería estar en la capa de presentación. Primero, no tiene nada que ver con la presentación, segundo, la implementación del procesamiento de una solicitud no es una preocupación para la capa de presentación. Compárelo con una aplicación web, presentar una TagItemResponse a un cliente es la preocupación de la capa web (presentación). Recuperar una instancia de TagItemResponse es la preocupación de una capa debajo de la capa de presentación.

Decidir si tiene una fachada entre la capa de su empresa y la capa de persistencia es difícil. Normalmente no implemento una fachada porque agrega una capa adicional (generalmente innecesaria) de indirección. Además, no veo ningún problema en llamar a los métodos de capa de persistencia directamente desde los métodos de la capa de negocios. Si solo tiene en cuenta el mismo principio: puede cambiar la implementación de la capa de persistencia sin afectar la implementación de la capa de negocios.

Saludos cordiales,

Ronald Wildenberg