Decoradores vs. clases en desarrollo web python

Question

He notado tres formas principales en que los frameworks web de Python manejan las solicitudes: decoradores, clases de controladores con métodos para solicitudes individuales y clases de solicitud con métodos para GET/POST.

Tengo curiosidad sobre las virtudes de estos tres enfoques. ¿Hay ventajas o desventajas importantes en alguno de estos enfoques? Para arreglar ideas, aquí hay tres ejemplos.

Bottle utiliza decoradores:

@route('/') 
def index(): 
    return 'Hello World!' 

Pylons utiliza clases de controlador:

class HelloController(BaseController): 
    def index(self): 
     return 'Hello World' 

Tornado utiliza clases de controlador de solicitudes con los métodos de tipos:

class MainHandler(tornado.web.RequestHandler): 
    def get(self): 
     self.write("Hello, world") 

Qué estilo es la mejor práctica ?

Answer 1

En realidad, hay una razón para cada uno de los tres métodos enumerados, específicos para cada proyecto.

• Botella intenta mantener las cosas tan simples /sencillo posible para el programador. Con los decoradores para las rutas no tiene que preocuparse sobre el desarrollador entendiendo OOP.
• El objetivo de desarrollo de los pilones es hacer que el código sea reutilizable y que sea fácilmente integrado con el enrutamiento de proceso HTTP estilo WSGI. Como tal, tienen elegido una forma muy OOP de organizar las rutas . Como ejemplo, podría copiar & pegar HelloController en cualquier aplicación Pylons y simplemente debería funcionar . Incluso si dicha aplicación es se sirve a través de WSGI en algún modo complicado .
• Tornado tiene una razón más para hacer las cosas de la manera que lo hace: IOLoop basada en epoll de Tornado (en conjunción con tornado.web.Application) crea una instancia de cada RequestHandler como solicitudes entran en juego.Al mantener cada RequestHandler limitado a un específico GET o POST esto permite que IOLoop a instancia rápidamente la clase, procesa la solicitud, y finalmente deja obtener basura recolectada. Esto mantiene de forma rápida y eficiente con una pequeña huella de memoria independientemente de cómo muchos RequestHandlers tenga su aplicación . Esta es también la razón por la cual Tornado puede manejar tantas solicitudes simultáneas más que otros servidores web basados ​​en Python (cada solicitud obtiene su propia instancia).

Ahora, habiendo dicho todo eso, debe saber que siempre puede anular el comportamiento del marco de trabajo predeterminado. Por ejemplo, escribí un MethodDispatcher para Tornado que lo hace funcionar más como Pylons (bueno, tenía CherryPy en mente cuando lo escribí). Reduce un poco la cantidad de Tornado (y aumenta ligeramente la huella de memoria) debido a que tiene un RequestHandler grande (a diferencia de muchos pequeños) pero puede reducir la cantidad de código en tu aplicación y hacer que sea un poco más fácil de leer (En mi opinión sesgada, por supuesto =).

Answer 2

Los diversos marcos están tratando de lograr el mejor rendimiento a través del mejor código (para escritura y lectura). Adoptan diferentes estrategias basadas en o alrededor de MVC o MVT.

Lo que se está enfocando probablemente se reducirá al gusto personal. Y también mi respuesta. Me esfuerzo mucho para evitar cualquier tipo de guerra santa porque puede haber argumentos técnicos válidos de los que no sé nada.

Pero yo personalmente prefiero mantener el enrutamiento separado del controlador (vista de django) y las plantillas separadas de eso. Hace que los controladores de reutilización sean realmente simples. Sí, soy un usuario de Django.

Como tal, realmente no soy un gran admirador de los decoradores de Bottle o envuelvo cosas en grandes y voluminosas clases. Solía ​​hacerlo cuando era desarrollador de ASP.NET pero Django me liberaba.