2010-05-26 29 views
5

¿Existe una mejor práctica en lo que respecta a dónde colocar la funcionalidad de registro en una aplicación MVC, por ejemplo, una aplicación Zend Framework (Zend_Log)? ¿Debería poner el registro en el controlador o en el modelo? ¿O en ambos?Inicio de sesión en MVC (Zend Framework)

Si está en ambos, ¿deberían tener el mismo registrador o uno diferente?

Respuesta

8

seguir el principio Information Expert en las directrices GRASP para el diseño orientado a objetos:

... coloque una responsabilidad en clases con la mayoría de la información necesaria para cumplir con ella.

Para que pueda escribir en el registro de la clase que contiene los datos que necesita para iniciar sesión. Si el evento que desea registrar pertenece al trabajo del modelo, escriba en el registro en el modelo. Si el evento desea iniciar sesión pertenece al trabajo del controlador, escriba en el registro en el controlador.

Crea una salida de registro para una aplicación. De lo contrario, tendrás que buscar entre muchos archivos de registro para encontrar información de diagnóstico. Puede almacenar un objeto de registro en el Zend_Registry para que pueda acceder al registro desde cualquier clase en su aplicación.


sus comentarios Re:

mejor simplemente fallan con gracia si el registrador no se encuentra bajo la clave de registro esperado. Por error, con gracia, me refiero a dar salida a un error a stdout (a la página web) o stderr (al registro del servidor httpd), o lanzar una excepción y dejar que la aplicación lo maneje.

En cuanto a las dependencias, esto no es un problema. Cada vez que una clase utiliza otra clase, tiene un tipo similar de dependencia. Consulte el patrón de diseño Registry.

+0

Pero con el registrador extraído del registro, el modelo tiene una nueva dependencia "oculta". Si utilizo el modelo en otra aplicación, tal vez sin registrar o almacenado con una clave diferente, entonces los intentos de obtener el registrador fallarán. Entonces, ¿deberían todos mis modelos crear una subclase de un modelo base que contenga métodos como log(), setLogger(), getLogger()? ¿O es eso demasiado exagerado? –

+0

Muy útil, muchas gracias. ;-) –

6

Estoy de acuerdo con Bill Karwin's comment, también usaría una sola salida de registro, pero también aprovecharía la capacidad de filter errors based on priority (por ejemplo, también hay un registrador Firebug que podría configurarse con facilidad).

En nuestra aplicación principal, tenemos un db-writer (que se convierte en un RSS-feed en un simple back-end de página) que también se utiliza como el registro principal y correos electrónicos para errores críticos. Muy útil para datos ordenables y obtener estadísticas de él.