Uso de procedimientos almacenados como capa de lógica de negocios

Question

La empresa para la que estoy trabajando utiliza actualmente los procedimientos almacenados (en el backend del servidor MsSQL) como su capa de lógica de negocios. La DLL de lógica de negocios real solo llama a los sProcs y básicamente administra la interfaz de usuario (eventos, enlace de datos, etc.)

Creo que hay algo mal en la configuración, aunque no estoy seguro de cómo explicarlo a mis colegas. Por cierto, el sistema funciona.

¿Están equivocadas las "mejores prácticas" en mi lugar de trabajo? ¿O estoy pensando demasiado?

Answer 1

GaiusSensei: está perfectamente bien trabajar de esa manera siempre que el dominio empresarial sea capaz de manejar cambios sísmicos en las prácticas comerciales. Creo que el debate todavía es común entre SP's y BLL dll y sin duda, habrá mucho en ambos lados en este hilo. Sin embargo, desde mi propia experiencia a través de una serie de proyectos en los últimos 10 años, aquí están mis observaciones que apoyan el enfoque DLL BLL:

• lógica contenida en el BLL puede ser 'agnóstico' del medio de almacenamiento y por lo tanto, más flexible para cambiar (aunque la frecuencia con la que ocurre esto es debatible )
• de grano más fino control sobre los negocios permisos en una serie de aplicaciones que dependen de la almacén de datos. Con esto me refiero a las tablas core cuya integridad debe ser mantenida en un nivel específico para , es uso dentro de la aplicación de negocios en cuestión.
• La lógica BLL se puede encapsular en self contiene clases que se pueden reutilizar en otras áreas del negocio y en el proyecto . La clase se puede incluso escrito como una clase cerrada o ampliable en función de su objetivo 'audiencia'
• Prueba de la unidad - esto (en mi experiencia ) es un arte negro si se utiliza el interior de SP. en java/C# etc., este es un estándar y algunos dirían práctica obligatoria ahora.
• Mantenibilidad. Manteniendo así las interfaces organizados dentro de una DLL BLL escenario, se hace fácil para apoyar a los desarrolladores ampliar sus clases sin romper la lógica existente
• Portabilidad.su BLL (dependiendo de la implementación del idioma) puede ser alojado en una variedad de plataformas. Del mismo modo, la inyección de la Implementación del almacén de datos puede literalmente ser cualquier cosa desde un archivo XML a mysql, postgres mssql etc, etc.
• Normalización. El arquitecto de datos puede definir exactamente cómo debe tomarse cada elemento de datos de la base de datos y cómo se debe guardar cada elemento (aunque esto se ubicaría mejor en una dll dll). Por lo tanto, el costo de entrada para los nuevos desarrolladores , así como sazonado, en el proyecto es mucho reducido.

La lista continúa, pero estos son mis mejores resultados para adoptar un enfoque BLL.

Buscando fwd a los muchos giros en este caso :)

Jim

[editar] - También me gustaría añadir que este BLL no debe emitir ninguna información de interfaz de usuario o bien, que no sea (como usted menciona) para transportar eventos, etc. cada capa de UI (relevante para el dispositivo de destino -navegador/dispositivo móvil/fábrica) debe hacer referencia al BLL y hacer su propio "thang" con los datos. Además, agregaría que debajo del BLL estaría su capa DAL. esta capa podría considerarse una referencia de 1-1 con el almacén de datos subyacente.

Answer 2

Hacemos eso.

Esto se debe a que admitimos escenarios en los que los usuarios se conectan a la base de datos utilizando programas distintos al software previsto (como, SQL Management studio, osql y Excel).

Cuando se conecta directamente a una base de datos que no es más que almacenamiento de datos, puede estropear todo ya que no hay reglas que lo detengan. Estas reglas solo existen dentro del programa que usa esta base de datos, y si no usa ese programa, puede usar sus permisos I-can-write-to-this-table para hacer cosas estúpidas (o divertidas).

Cuando solo tiene permisos para ejecutar procedimientos almacenados, no puede.
Personalmente creo que es un mejor enfoque.

Answer 3

Diría que los procedimientos almacenados no se prestan para la prueba unitaria y la refactorización casi tan bien como la lógica de la capa de negocios en, por ejemplo, .net/java. Mantendría la lógica fuera del DB lo más posible, la principal excepción sería establecer inherentemente operaciones en las que un DBMS sería excelente.

Answer 4

(I añade la etiqueta "subjetiva")

prefiero utilizar procedimientos almacenados, excepto en pequeñas aplicaciones que sacar de repente debido a jugar un poco con los procedimientos almacenados toma un poco de tiempo extra.

Christopherous 5000: todavía se pueden hacer las pruebas unitarias con procedimientos almacenados

estoy de acuerdo con la respuesta de estas dos preguntas similares:

• Business Logic: Database or Application Layer

• Should the data access layer contain business logic?

Answer 5

Parece que su Business Layer es realmente la capa de datos y su aplicación no tiene Business Layer, pero estoy divagando ...

Las mejores prácticas están sobrevaloradas y cambian con el tiempo. Si lo que están haciendo funciona y están contentos con él, entonces no hay mucho que se pueda hacer.

No puedo decirte en cuántos proyectos he estado cuando el nuevo tipo sube a bordo y piensa que la arquitectura actual debe cambiarse. Lo he hecho algunas veces yo mismo. No es un buen lugar para estar. El status quo luchará contigo hasta el final. Si realmente está decidido a cambiar el sistema actual, cree cierta credibilidad. En 3 a 6 meses comenzar a sugerir mejores formas de acercarse a parte de la infraestructura existente.Si realmente no le gusta la arquitectura actual, abandone la empresa.

La aplicación fue escrita con las mejores intenciones. El desarrollador original se vio limitado por el tiempo, la experiencia y la tecnología.

Las aplicaciones como la que describió son buenas oportunidades de aprendizaje. Tenga en cuenta los puntos de falla, aprenda de sus éxitos. Te sorprenderá lo que aprendas.

Answer 6

Creo que los procedimientos almacenados están bien como parte de su lógica comercial. No creo que deba tener toda la lógica de su negocio en una dll. Sin embargo, si tiene una capa empresarial que administra la interfaz de usuario, creo que debe separar la administración de la interfaz de usuario de la capa empresarial con algún tipo de marco. La separación debe ser funcional, no incruste datos en sus procedimientos almacenados o su lógica de negocios y viceversa. También creo que si tiene otros programas, como Excel o informes, acceda a los datos que deberían ingresar a través de una fuente de datos discreta, servicio web o lo que sea.

Utilizo para trabajar en sistemas de servidor de cliente con mainframes donde se obtiene una separación real de tres capas y una inflexibilidad real de los huesos. Las aplicaciones modernas deben ser un poco más abiertas en la implementación y tener reglas comerciales, en particular para la validación, en todas las capas. Eso no significa que su modelo de diseño no pueda tener separación, es solo que las reglas comerciales como 'está en blanco o el día de la semana' tienen que implementarse a través de la interfaz de usuario, la capa empresarial y los datos.

Si lo que tienes funciona, solo calcula cómo trabajar con él en el futuro.

Answer 7

Depende.

Depende de lo que llame lógica de negocios.

Ciertas cosas deben ser aplicadas en la base de datos, particularmente cualquier cosa donde algún otro proceso tenga suposiciones sobre la naturaleza de lo que presenta la base de datos.

Si todos los usuarios de la base de datos suponen que cuando se desactiva el último descendiente de una parte de facturación, el estado de la parte de facturación debe modificarse, entonces esto debe aplicarse en la base de datos, ya sea en un SP que es el único forma de realizar la operación o un disparador, o una restricción o algo. Este es el tipo de cosas, lógica de negocios de bajo nivel que es realmente lógica de integridad de datos crítica a nivel de negocios, lo cual está bien tener en la base de datos. La lógica de negocios de alto nivel no cabe en la base de datos; por ejemplo, cuando un paciente cancela su última cita y necesita pasar a una lista de retirada, no es un problema de integridad de datos; todos los que llaman no asumen que los pacientes sin citas deben estar en la lista de retiro.

La distinción es sutil y es por eso que las personas tienen dificultades con la lógica de "negocios" en la base de datos. Recomiendo solo cosas que se supone que la base de datos protege y presenta en el perímetro de la base de datos a todos los usuarios de la base de datos implementada en la base de datos; esta lógica empresarial está por debajo de la capa DAL y forma parte del diseño fundamental de la base de datos. Todavía defiendo en las arquitecturas tradicionales un DAL ciego a los negocios por encima de eso y un verdadero BLL por encima de eso.

Habiendo dicho eso, ciertamente es posible cuando el DAL es un bombeo de SP muy trivial tener su lógica de negocios de nivel superior también en la base de datos, y cuando lo hace, no está tan claro qué cosas son de bajo nivel y que son de alto nivel (a menos que tenga dos bases de datos, una construida sobre la otra, lo cual no es necesariamente una idea terrible). De hecho, ha escrito una parte de su lógica empresarial en SQL en lugar de una aplicación de cliente tradicional.

Eso no significa necesariamente que sus capas estén demasiado unidas o que tenga una mala arquitectura: al igual que cualquier sistema, la elección del idioma para las diferentes capas no necesariamente apunta a un problema arquitectónico. Solo mirando las capas puede decir si tiene un problema arquitectónico.

Answer 8

¿Qué pasa si su compañero de trabajo quiere reutilizar su capa de negocios con MySQL? Le dirá que es imposible porque parte de la capa de negocio reside en SQL Server ...