Arquitectura: Patron Repositorio ¿Donde se coloca "la capa de negocio" ?

[chcma]

Buenas foreros,

A ver si alguien puede resolverme esta duda sobre Arquitectura con el patrón repositorio el cual estoy estudiando ahora mismo.

Bueno, para mis estudios me he creado un proyecto Web (MVC) y un proyecto de tipo Libreria donde tendré el Dominio.

- HSoft.Samples.Library.Domain (Proyecto de tipo Libreria)
* Abstract (Carpeta donde tengo las interfaces)
* Entities (Carpeta donde tengo mis entidades)
* Repository (Carpeta donde tengo los Repositorios)

- HSoft.Samples.Web (Aplicativo MVC)


Bien, pues mostrando esto, y esperando ser claro, me surgen tres pequeñas dudas.

1-. En mis repositorios, por ejemplo, en un método que fuera AddClient(), si quisiera validar ciertos casos previamente respecto a la BBDD, o respecto a la entidad misma.. ¿Estaría bien, arquitectónicamente hablando, si introduzco estas validaciones dentro del mismo AddClient() ?

Es decir, yo sé que en mi Aplicación MVC tendré que hacer las validaciones correspondientes de mi Model antes de mandarlos al AddClient del repositorio. Pero.. hay ciertas validaciones del Dominio (Como por ejemplo, si la entidad tiene la Propiedad Sexo=Mujer y la propiedad Profesion=Futbolista, mandar Excepcion) que obviamente quiero que se hagan en el dominio, y así tanto mi aplicativo MVC, como un aplicativo Windows, usando directamente la librería del Dominio, ya no tenga que preocuparse de esto. Entonces.. ¿Es correcto meter estas validaciones en el AddClient() o no?

2.- Doy por echo que un Repositorio no tiene por que ser un reflejo de una tabla, ¿Verdad? Es decir, si tengo la tabla Orders y la tabla Details, perfectamente podría tener un Repositorio que fuera OrdersRepository, y que ahí el método AddOrder() recibiera una entidad de tipo Order con una propiedad Details, y que se almacenase todo desde AddOrder(). ¿Eso estaría bien, verdad?

3.- Entiendo que la librería de Dominio, es donde está toda la lógica y el corazón de la aplicación. Entidades que se usarán y demás. Hasta ahí correcto. Entonces... si quiero desarrollar un WebService tipo WCF... ¿Estaría correcto que estas entidades les metiera ahí los DataMember y demás atributos aun que estas entidades luego también se vayan a usar desde un AppWindows, o desde mi propia app MVC?

En fin... espero haberme explicado, y alguien que se le de bien el tema de Arquitectura me pueda orientar un poco.

Gracias por todo, y especialmente al que se haya tomado la molestia de leer todo lo que acabo de poner, que sé que es mucho, jeje.

Un Saludo !!!!!

[alan_69niupi]

Hola.
1. Las validaciones en la capa de datos siguiendo la arquitectura únicamente deben validar si son datos nulos o no, ya que en esta capa deben llegar los objetos o instancias y nadie más que las clases que estén a este nivel en la arquitectura deben acceder a estas clase, es decir deber hacer las validaciones desde que retomes los valores en la aplicación.

2. esta correcto lo que piensas.

3. recuerda que en los webservices los datos que recibe son de orígenes xml o json. toma en cuenta esto para llama tus entidades.


espero te ayude

Saludos!!!!

[chcma]

Buenas alan_69nipui,

Muchas gracias por tu contestación.

Creo que la 2 y la 3 las tengo claras.

Sobre la 1... Ahí lo tengo menos claro.. ¿Donde harías la validación que te comento entonces? Por ejemplo... Supongamos lo siguiente:

No se puede insertar un Order con details que ya existan en algún otro Order que ya esté en la BBDD. ¿Esa validación... donde la pondrías si no es en el repositorio?

[alan_69niupi]

a okas, ya entendí, ahí puedes usar transacciones.
yo uso 3 capas de objetos
1. objetos de negocio
2. objeto de acceso a datos
3. reglas de negocio.

me explico:
la capa uno donde estan las relaciones de mis clases principales donde digo que propiedades tiene cada clase, herencia, polimorfis, todo eso. aqui no haya nada de validación
la capa dos es donde unica y exclusivamente hago querys. en esta capa solo hago validaciones de datos nulos es decir y requiero un dato solo pregunto si es nulo, si no es continuto si es nulo lo levanto con una excepcion. estas clases son internal
la capa tres es donde hago las validaciones, aqui hago la transaccion cuando hago movimientos a más de una tabla. esta es unica capa que tiene acceso a mi capa de datos. en esta capa es donde recepciono las excepciones y esta la envia a mi aplicación. siempre manejo try catch para el manejo de excepciones. en fin en esta ultima capa valido que exitan datos. primero consulto si trae datos entonce procedo a insertar. recalco todo eso es dentro de una transaccion esto es muy importante.

espero te sirva

Saludos!!!!