architecture - DAL/BLL y Cliente/Servidor: ¿Debería el cliente usar objetos BLL o DAL para la presentación? O tal vez otra capa(objeto de transferencia de datos?)

data-access-layer data-access

Question

Estoy escribiendo un sistema cliente / servidor. El servidor tiene un diseño DAL / BLL. El cliente es responsable de presentar los objetos de datos y proporcionar diálogos y asistente para permitir al usuario actualizar estos objetos (es decir, agregar / editar un usuario).

Inicialmente pensé que simplemente haría que los objetos DAL tuvieran un objeto proveedor de datos universal para que puedan ser utilizados tanto por el cliente como por el servidor. Por ejemplo, cuando el servidor utiliza el objeto de datos, la base de datos es el proveedor de datos; cuando el objeto de datos está siendo utilizado por el cliente, el servidor es el proveedor de datos.

Entonces un objeto se cambia en la capa de presentación, por ejemplo un "usuario": usuario-> setNombre ("Fred"), y luego lo confirma como este usuario-> confirmar (), el método de confirmación llama al método de confirmación del proveedor de datos, que luego codifica el objeto y lo envía al servidor. El servidor luego lo "decora" con el objeto de la capa de negocios y continúa desde allí.

Actualmente tengo esto funcionando como un prototipo, con los objetos DAL definidos en un proyecto compartido que se usa tanto por el cliente como por el servidor. El servidor luego inyecta su proveedor de datos (que usa la base de datos) y el cliente inyecta un proveedor de datos que usa el servidor.

Me pregunto si esto parece un enfoque razonable. Me pregunto si necesito otra capa en lugar de tener los objetos DAL expuestos directamente al cliente. Tal vez una capa de objeto de transferencia de datos, que me daría 3 capas: objetos de acceso a datos, objetos de lógica de negocios y objetos de transferencia de datos.

Gracias.

Answer 1

No es una buena idea exponer ''objetos internos'' como objetos usados ​​/ devueltos comprar el DAL. Es mejor mantener todos los objetos internos ocultos del cliente y tener un conjunto completo de objetos para la comunicación entre el cliente y el servidor. Puede ser algo de trabajo extra convertir un objeto en otro, pero facilitará la actualización del sistema en caso de que el servidor y el cliente no se actualicen juntos.