2008-08-06 26 views
9

Actualmente estoy trabajando en un proyecto con requisitos específicos. Una breve descripción de estos son como sigue:Disparadores de eventos basados ​​en temporizador

  • datos se recuperan de servicios web externos
  • Los datos se almacenan en SQL 2005
  • datos se manipula a través de una interfaz web
  • El servicio de Windows que se comunica con el los servicios web no tienen acoplamiento con nuestra UI web interna, excepto a través de la base de datos.
  • La comunicación con los servicios web debe basarse tanto en el tiempo como en la intervención del usuario en la interfaz de usuario web.

El modelo actual (prepreproducción) para la activación de la comunicación del servicio web se realiza a través de una tabla de base de datos que almacena las solicitudes de activación generadas a partir de la intervención manual. Realmente no quiero tener múltiples mecanismos de activación, pero me gustaría poder completar la tabla de la base de datos con desencadenadores según la hora de la llamada. Como lo veo, hay dos formas de lograr esto.

1) Adapte la tabla de disparadores para almacenar dos parámetros adicionales. Uno de ellos es "¿Está basado en el tiempo o agregado manualmente?" y un campo anulable para almacenar los detalles de tiempo (se debe determinar el formato exacto). Si se trata de un desencadenador creado por manaul, márquelo como procesado cuando se disparó el desencadenador, pero no si se trata de un desencadenador temporizado.
o
2) Cree un segundo servicio de Windows que crea los desencadenantes sobre la marcha en intervalos de tiempo.

La segunda opción me parece un dulce de azúcar, pero la administración de la opción 1 podría convertirse fácilmente en una pesadilla de programación (¿cómo se sabe si la última encuesta de la tabla devolvió el evento que debe disparar y cómo luego dejes de reactivarlo en la próxima encuesta)

Agradecería que alguien pudiera dedicar unos minutos para ayudarme a decidir qué ruta (una de estas dos, o posiblemente una tercera, no incluida en la lista) tomar .

Respuesta

1

¿Por qué no utilizar un trabajo SQL en lugar del servicio de Windows? Puede encapsular todo el código de "activación" de DB en Procedimientos almacenados. Luego, su UI y SQL Job pueden llamar a los mismos Procedimientos almacenados y crear los desencadenantes de la misma manera, ya sea manualmente o en un intervalo de tiempo.

0

La forma en que lo veo es esto.

Tiene un Servicio de Windows, que desempeña el papel de un programador y en él hay algunas clases que simplemente llaman a los servicios web y colocan los datos en sus bases de datos.

Por lo tanto, puede utilizar estas clases directamente desde la WebUI e importar los datos en función del desencadenador WebUI.

No me gusta la idea de almacenar una acción generada por el usuario como una bandera (activador) en la base de datos donde algún servicio la interrogará (en un intervalo que no está bajo el control del usuario) para ejecutar esa acción.

Incluso puede convertir todo el código en un exe que luego puede programar con el Programador de Windows. Y llame al mismo exe siempre que el usuario active la acción desde la IU web.

0

@Vaibhav

Por desgracia, la arquitectura física de la solución no permitirá ninguna comunicación directa entre los componentes, distintos de interfaz de usuario web de base de datos y base de datos para el servicio (que luego se llamarán a los servicios web) .Sin embargo, estoy de acuerdo en que la reutilización de las clases de comunicación sería lo ideal aquí. Simplemente no puedo hacerlo dentro de los límites de nuestro negocio *

* No es siempre la forma en que técnicamente " mejor "solución está obstaculizada por factores externos?