2010-02-19 16 views
5

Estoy escribiendo una aplicación ASP.NET que tengo una capa UI, capa de lógica de negocios y capa de acceso a datos. Desde mi capa de datos devuelvo objetos comerciales a la capa de lógica de negocios y los paso a la capa UI. Sin embargo, no estoy seguro de qué hacer cuando deseo realizar un guardado/inserción con datos de la capa UI.¿Qué debo devolver de la capa UI a la capa empresarial?

¿Debo crear el objeto comercial en la capa UI y pasar a la capa empresarial o debería crearlo en la capa empresarial?

muchas gracias

+0

gracias a todos por sus comentarios - muy apreciado – Nick

Respuesta

2

Estoy de acuerdo con crunchdog: para todas las aplicaciones web menos triviales, debe tener una forma plana de sus objetos comerciales específicamente para su capa de interfaz de usuario/vista. A veces esto se conoce como una clase de modelo de vista y generalmente no contiene más que varias propiedades de cadena que la capa de interfaz de usuario puede obtener y poner directamente sin preocuparse por la validación. (Ver asp.net mvc)

Por un lado, esto mantiene el limpiador capa de interfaz de usuario y más simple, dejando a la puso es esfuerzos hacia la visualización de los datos en lugar de atravesar estructuras de objetos, la revisión y la interpretación de los nulos, etc.

Esto también le da a la capa empresarial la oportunidad de validar esos valores de cadena, devolviendo los valores tal como se ingresaron si no son válidos. Esto puede ahorrar frustración de codificación cuando, por ejemplo, su servidor tiene que manejar una fecha no válida en un campo de fecha. La capa empresarial, que reconoce los valores no válidos, puede devolverlos exactamente como se recibieron junto con los mensajes de error adecuados. Si todo lo que manejaste fueron objetos de negocios/dominio, entonces algunos valores ingresados ​​pueden no ajustarse a los objetos destinados a contenerlos.

También puede ayudar tener una clase designada para mapear valores hacia atrás y hacia adelante entre los objetos de negocios/dominio y el modelo de objeto/vista de UI. Esto ayuda a mantener las preocupaciones de la capa empresarial separadas.

0

me parece mejor tener objetos de la capa de interfaz de usuario que modelan los objetos de negocio "reales". Estos objetos modelo no necesitan tener toda la información (asociaciones y demás) que tienen los objetos comerciales "reales". Luego, la capa de negocios debe estar a cargo de la conversión desde y hacia los objetos de negocios.

Para aplicaciones web, esto es particularmente útil, ya que no necesita enviar datos excesivos al cliente.

+0

Crunchdog está hablando de objetos de transferencia de datos o DTO para abreviar: http://en.wikipedia.org/wiki/Data_transfer_object. – Steven

0

Si no desea una codificación excesiva de un objeto comercial, ha hecho lo correcto al recuperar los datos (en los que devuelve el mismo objeto comercial de DAL a BL a la interfaz de usuario).

Al guardar los datos, lo que podría hacer es pasar esos objetos como parámetros en su capa BL y \ o DAL. Puede devolver el objeto actual si lo vinculó en su control de UI o crear una nueva instancia de ese objeto y establecer los cambios realizados.

Luego, en su capa DAL, simplemente lea el objeto y guarde los cambios nuevamente en la base de datos.

0

He encontrado que la solución más fácil es tener un objeto de modelo de vista pasado de la interfaz de usuario a la capa de negocios, por un par de razones. Lo más obvio es que la validación debería ocurrir en la capa de negocios, por lo que la creación de un objeto comercial en la interfaz de usuario rompe los principios de MVC.

Más importante aún, si el usuario ingresa datos no válidos, un objeto comercial puede (correctamente) no ser capaz de aceptar esos datos.Sin embargo, no desea descartar los datos ingresados ​​por el usuario, por lo que un objeto de modelo de vista sin validación le brinda una forma de almacenar y pasar los datos ingresados ​​por el usuario, independientemente de si son válidos o no.

Cuestiones relacionadas