Capa de Servicio vs. Helper Objects?

Question

Me gustaría tener su opinión sobre un caso específico, por favor. Esto se trata de capa de servicios vs. Helper Objects - y no estoy en busca de patrones idealistas, sino simplemente una buena comprensión de lo que mis colegas de programación queridos piensan acerca de esto:

En mi aplicación actual que tengo un modelo de dominio completo (LINQ to SQL, repositorios extremadamente ligeras y luego usar los métodos de extensión a través de IQueryable <> para filtrar / tipo / orden basado en los requerimientos del negocio), y luego una capa de servicios que contiene los servicios basado en la agrupación de las responsabilidades, tales como IRegistrationService (registrar usuarios, comprobar la disponibilidad de nombres de usuario, etc.)

Ahora la advertencia. También tengo algunas clases de "ayudante" que aparecen cosas como el cifrado, y también he rellenas otros elementos de lo contrario ungroupable en ese directorio (como enumeraciones personalizados, etc.)

Es necesario crear una nueva clase ahora que se encargará de la generación de vínculos personalizados para mi aplicación, que es poco más que String.Format con diferentes objetos y teniendo en cuenta sus propiedades. El funcionamiento interno son irrelevantes. Sin embargo, tengo un tiempo difícil crear instancias de una especie de "linkservice" ahora que voy a hacer eso - Siento que voy a terminar con 100 servicios (y sus interfaces de aplicación +) cuando he terminado

Al mismo tiempo no me siento como que quiero crear un poco de mezcla suelta de clases y otras cosas en mi "ayudantes" espacio de nombres / directorio (por ejemplo LinkManager).

¿Qué hacer? ¿Por dónde chicos poner cosas que es todavía algo nivel de la capa de negocio, pero al mismo tiempo, ¿cómo limitar el número de elementos en la capa de negocio / servicio? ¿Dónde se adhieren todas esas clases de ayuda pequeñas, como los objetos intermedios que simplifican y gestionar el acceso de Sesión (supongo que desea tener esta fuertemente tipado - al menos yo)

?

Déjame saber lo que piensa? Gracias!

Answer 1

Para mí, el uso de la herramienta adecuada para el trabajo es la clave. Si necesita algún tipo de instalación para generar enlaces, que es básicamente un mapeo de las propiedades de la entidad a las cadenas de formato, a continuación, escribir una facilidad para hacer eso. No tiene que ser un servicio ... por el contrario, tener un servicio completo soplado para algo como esto es algo excesivo. Sin embargo, no me acaba de agrupar a esto en sus "ayudantes" generales. Suena como esto es algo que tiene un propósito y una intención específica, con un tipo específico de comportamiento detrás de él. Como tal, lo puso en un lugar adecuado apropiadamente para que el comportamiento ... incluso si eso es un nuevo proyecto.

Trato de no tener un enorme trozo de código de "general" en mis aplicaciones. Todo tiene un propósito e implementa un comportamiento específico. A veces ese propósito y el comportamiento son altamente reutilizables, pero todavía tratan de organizar los elementos reutilizables de mi dominio lógicamente. A partir de un alto nivel, veo la mayoría de mis aplicaciones divididas en las siguientes:

1. Cliente
2. API / Servicio
3. Dominio
4. acceso a datos (opcional)
5. Marco

Una gran cantidad de este tipo de funcionalidad reutilizable cae en una especie de región inferior entre el marco y de dominio. Parte de ello puede existir como algunas clases de base y / o interfaces y tipos de apoyo en el marco, con la otra mitad, las implementaciones concretas, que reside dentro de mi dominio. A veces parece extraño, pero la organización de esta manera me ayuda a mantener mi dominio lo más limpio posible (dedicado a las preocupaciones de negocios), mientras que todavía me permite a conceptos comunes y reutilizables abstractos en los tipos de nivel inferior "marco".