Agregar métodos a las clases POCO

Tengo la siguiente configuración: MVC> Servicios> Repositorios. Ahora quiero permitir que los usuarios puedan agregar una Nota a un Documento. Solo los usuarios asociados con el documento (ya sea como propietarios o los colaboradores) se pueden añadir notas así que en mi NoteService Yo lo siguiente para garantizar que el usuario tiene permiso en el documento seleccionado:Agregar métodos a las clases POCO

public Note GetNewNote(int documentID) 
    { 
     if (!userHasAccess(Thread.CurrentPrincipal.Identity.Name)) 
      throw new BusinessLogicException(); 

     // Other stuff here... 
    }

Mi pregunta es, ¿dónde debería definir el método userHasAccess? No tiene sentido en NoteService ya que está comprobando en un documento. Podría definirlo en el DocumentService pero luego NoteService necesitará acceder a esto, lo que parece estar introduciendo más acoplamiento.

Para mí tiene más sentido definirlo en el documento POCO y luego llamar a document.userHasAccess (...). ¿Sería esta una buena práctica o un dominio POCO debe limitarse a propiedades simples? Me preocupa que esto sea realmente parte de la validación y que al ubicar el método en POCO estoy separando la validación entre el Servicio y POCO.

Lo que estoy tratando de asegurar es que mi aplicación es fácil de mantener y probar. ¡Cualquier sugerencia sobre cómo debo abordar esto sería muy apreciada!

Fuente

2011-12-16 James

¿Qué tipo de cheque no userHasAccess hacer? Code Access Security podría funcionar para usted. – jgauffin

Simplemente comprueba que el Usuario esté en Document.Owners o Document.Reviewers: estas son muchas o muchas relaciones entre Document y Person. – James

¿Dónde debería definir el método de usuario HasAccess?

Tiene sentido ser coherente con el resto del diseño, aunque no conozco el diseño completo al menos puedo decir que un método llamado UserHasAccess() en el POCO tiene sentido.

¿Debe un dominio POCO limitarse a propiedades simples?

No, un dominio POCO debe contener lógica (especialmente lógica de validación) relacionada con el objeto. De lo contrario, termina siendo un object with no behaviour, algo que definitivamente deberías evitar.

Sin embargo, no se confundan entre un objeto de dominio (negocio) y un objeto de vista, que generalmente contiene poca lógica.

Le preocupa que esté separando la validación entre Servicio y POCO.

Pondría la validación en el POCO, y la lógica entre dominios en los servicios.

Fuente

2011-12-16 14:24:26

Gracias por la respuesta y el enlace. Para impulsar esto un poco más, ¿qué tipo de validaciones tienden a aparecer en POCO? ¿Son cosas como en mi ejemplo, métodos simples que luego son llamados por un Servicio? Entonces, ¿un servicio puede llamar a los que necesita para determinar si una excepción de validación (o lo que sea) debe arrojarse al controlador? ¿O debería haber algún tipo de método de validación en mis POCO? – James

Tendría un método de validación en cada POCO - tiene sentido que un POCO sepa si es válido. Sin embargo, su ejemplo es un poco diferente y tiene sentido ser un método en sí mismo. –

La idea del método de validación me confunde porque los diferentes métodos de Servicio requerirán cosas diferentes para llamar al POCO válido. Con mi ejemplo, userHasAccess solo está preguntando al POCO si podemos hacer algo, mientras que un método de validación en mi mente haría las comprobaciones como "el nombre de usuario debe ser único". ¿Esto no comienza a unir al POCO con EntityFramework? – James

Cualquier entidad de dominio también puede contener métodos de validación.

Fuente

2011-12-16 13:59:17

¿Es esta una buena práctica?No quiero comenzar a agregar estos métodos aparentemente simples a mis clases de POCO solo para descubrir más adelante que es difícil de mantener/probar. Sería bueno mantener toda la validación en una sección. Con el ejemplo anterior, podría simplemente verificar si el Usuario está en document.Owners y luego si está en el documento. Revisores, pero tendré que repetir esta lógica una y otra vez, así que necesita ser su propio método. – James

Si sigue Domain Model Pattern entonces puede agregar atributos con comportamientos. comprobar esto Martin fowler
Si usted está siguiendo el patrón módulo de la mesa a continuación, añadir comportamientos en clase BLL y atributos en POCO cheque esto también por Martin fowler

Fuente

2011-12-16 14:51:59

Respuesta

Cuestiones relacionadas