Dónde mover la lógica de negocio cuando se mueve fuera de la base de datos

Question

Tengo una aplicación ASP.NET ABM-pesado con toda la lógica de negocio en procedimientos almacenados.

A modo de ejemplo, existe un procedimiento de actualización almacenado que es ~ 500 líneas de largo y contiene grandes cantidades de lógica condicional, que hacen referencia a varias tablas y UDF. El proc lleva en el nombre del campo que se actualiza y el nuevo valor, establece un montón de variables declaradas, hace un montón de validación y crea una sentencia de SQL dinámico para hacer la actualización. Una vez talla única. Es grande y confuso.

Me gustaría mover la lógica de negocio a un lado .NET para que sea más fácil de manejar / actualización, prueba y puesta bajo control de código fuente.

Mi pregunta es la siguiente: en caso de que esto vaya lógica de negocio?

Decir que tengo un objeto PurchaseOrder con una propiedad llamada 'fábrica'. Si la fábrica se cambia, lo que asegurarse de que la nueva fábrica asignado hace que el producto que está en la PurchaseOrder, que tiene la fijación de precios, y que hay una cantidad mínima pedida en base a esa fábrica, etc. Todas estas validaciones requieren investigaciones en el base de datos.

¿Debería haber colocador de fábrica del objeto PurchaseOrder ser responsable de hacer la validación de datos a través de un método / propiedad 'isFactoryValid' que hace que las múltiples llamadas a un objeto de acceso a datos genéricos y luego hacer la actualización si lo es?

O creo un / PurchaseOrder objeto de base de datos 'proxy' que es responsable de manejar el acceso a datos simplemente relacionada con PurchaseOrder. En este caso, habría de tener un método 'isFactoryValid' en el proxy que se llama por el colocador del PurchaseOrder y luego una llamada al método de actualización del proxy?

¿Cómo determino si necesito que preocuparse por el aumento de tráfico a la base de datos con todas estas llamadas adicionales?

Answer 1

Hay dos patrones principales que son ampliamente utilizados para implementar la lógica de persistencia de la base de datos:

• ActiveRecord Patrón -. La persistencia es la lógica en su objeto de dominio
• patrón Repositorio - Un objeto o capa separada maneja el acceso a los datos - su "proxy" direcciones concepto esto.

El truco de los dos objetos es saber cuándo hay que hacer un viaje a la base de datos y saber cuándo no . Por ejemplo, hay las validaciones redundantes que se realizarán entre el PP y la capa de dominio, por ejemplo, incluso antes de hacer una base de datos llamada se debe evaluar para no valores nulos, truncar cadenas de longitud, etc. . Sólo después de que se han hecho se debe hacer una llamada para ahorrar en el PP estas comprobaciones.

También hay una amplia gama de estrategias disponibles para aumentar el rendimiento o reducir al mínimo los viajes de bases de datos, al igual que la carga diferida, transacciones, y similares.

Answer 2

Una forma de hacerlo: Usted tiene una capa de datos en .NET (una o varias clases de datos) con una interfaz para la capa ... entonces usted tiene una capa de negocio que realiza la lógica de negocio mediante la interfaz. http://en.wikipedia.org/wiki/Multitier_architecture

Answer 3

También puede transformar su lógica de negocio en trozos de servicios web reutilizables. WCF proporciona un gran apoyo de herramientas.

Answer 4

Mira en Domain Driven Design (DDD) que responderá a un buen número de sus preguntas. Se habla de Repositoryies para acceso a datos y la especificación para las validaciones. Un buen ORM también ayudaría. Este libro es también grande:

texto alternativo http://img117.imageshack.us/img117/5282/032112521501aa240sclzzzzzzzv38088225zh7 .jpg

Answer 5

Esto dependerá del modelo de objetos que ha creado y cómo has dejado que su interlocutor decidir qué fábrica será la nueva fábrica para procesar el PurchaseOrder.

Por ejemplo, si se le da a su interlocutor una lista de fábricas que pueden elegir, puede filtrar la lista a sólo aquellos que apoyan el producto asociado con el PurchaseOrder existente (estoy asumiendo que usted está editado una orden existente) . Si usted quiere tener la PurchaseOrder validar que la fábrica puede procesar el pedido, lo habría hecho el organismo en el PurchaseOrder llamar a un método en la fábrica (algo así como CanProcessOrderFor (producto, cantidad)).

Estoy asumiendo que se ha tenido que hacer una consulta de base de datos ya para obtener la lista de las fábricas y la PurchaseOrder. Tendría la consulta para los objetos de fábrica devuelven su lista de productos compatibles y las cantidades corrientes (o pedido mínimo - sea cual sea su lógica tiene que ser).

Un buen ORM como NHibernate le permitirá almacenar en caché algunos de estos resultados para minimizar ida y vuelta si se trata de un escenario común.