¿Crea clases para manejar "entidades" para aplicaciones controladas por datos?

Question

Soy un novato y cuando me entretuve creando aplicaciones de bases de datos, siempre creé mis formularios y puse todos los códigos y enlaces allí. En lugar de tener matrices y listas que contenían información, realicé cambios en la base de datos directamente.

Ahora que he evolucionado un poco, digamos que vendí widgets a clientes y guardé la información de ventas en una base de datos. Si estuviera escribiendo un programa para acceder a la base de datos, ¿no querría crear una clase de tipo 'Cliente' y 'Widget' para trabajar con esas entidades?

Si me equivoco, ¿cuál es el enfoque apropiado para programar aplicaciones de bases de datos?

Answer 1

Sí.

Desea consultar n-tier .

Básicamente, le permite el acceso de front-end (capa de presentación) solo a su biblioteca de clases (capa de negocios). Su biblioteca de clases luego accede a su base de datos.

Esto le brinda una solución menos acoplada y permite un código más mantenible. Además, al introducir niveles permite cambios en su base de datos sin la necesidad de volver a escribir código en su interfaz, siempre que no sea necesario cambiar la interfaz con la capa empresarial.

En lo que respecta al enlace, si está utilizando Windows Forms de Visual Studio (2005 en adelante), debería poder usar un bindingSource que luego puede usar para enlazar sus controles. Si está utilizando ASP.NET, su control debería enlazarse a una lista de objetos sin ningún problema.

Para ASP.Net, ObjectDataSource podría ser útil . No lo he usado, pero hay muchas muestras en la web. Pruebe aquí o here .

Answer 2

Sí.

Desea mirar de cerca Asignación de objetos y relaciones .

Sus entidades comerciales del mundo real están modeladas por objetos que se asignan a tablas relacionales.

Answer 3

No desea que su capa de presentación dependa directamente de la estructura de su base de datos; el problema con eso es que si la estructura de su base de datos cambia, su capa de presentación debe cambiar, ya largo plazo, eso puede causar problemas. Además, existen problemas de seguridad relacionados con la interacción directa de la capa de presentación con su base de datos.

La analogía aproximada aquí es a los mercados; cuando vas a la tienda a comprar una barra de pan, no necesitas saber cómo cultivar trigo; todo lo que necesita saber es que usted tiene dinero y ellos tienen pan, y que intercambiarán cierta cantidad de pan por cierta cantidad de dinero. No necesitas saber en qué época del año para plantar el trigo, ni cómo eliminar la paja, ni nada de eso, porque la capa de soporte se encarga de eso por ti. De manera similar, el agricultor no necesita saber cómo vender pan a un grupo completo de personas, o incluso cómo hacer pan; todo lo que tiene que hacer es saber cómo cultivar trigo.

La filosofía de diseño moderno recomienda que uses una capa intermedia para interactuar entre la capa de presentación y la capa de la base de datos; Aquí es donde pones tu lógica de negocio. Entonces, por ejemplo, supongamos que está vendiendo widgets en su sitio. En lugar de que su código de presentación consulte los widgets de la base de datos y muestre eso, tiene un objeto de negocio que maneja sus widgets. De esta manera, su objeto de negocio necesita saber cuál es la estructura de su base de datos, pero su capa de presentación solo necesita saber cómo pedirle a su objeto de negocio una lista de widgets para mostrar. Más importante aún, en su objeto comercial puede colocar las reglas que deben invocarse cuando suceden ciertas cosas. Entonces, en lugar de que su capa de presentación realice cambios en la base de datos para el inventario y los pedidos cuando se realiza un pedido, su objeto comercial sabe cómo realizar los cambios y qué tablas modificar cuando su capa de presentación solicita que se realice una venta.

De esta manera, separa la visualización de su información de la persistencia y la lógica subyacente del sitio web. Lo que está involucrado es una buena planificación; específicamente, tiene que averiguar qué hará su sitio web en un momento dado, y qué significa eso en términos de las interfaces que proporcionarán sus objetos comerciales. Luego implementas tus objetos de negocio basados ??en esos requisitos; esos objetos de negocio son donde pone el conocimiento de la estructura de la base de datos y su lógica de negocio específica (" cuando A sucede, haga B y luego C " ;, etc.).

Esto parece mucho trabajo extra al principio, pero realmente vale la pena.