Resumen de las preguntas de entrevista imprescindibles de Django

El artículo se transfiere desde
https://blog.csdn.net/weixin_43063753/article/details/85559540

Contenido
inserte la descripción de la imagen aquí
Bienvenido a seguir
1 Haga una lista de los métodos de solicitud comunes en las solicitudes Http
2 Hable sobre su comprensión del protocolo HTTP. 1.1 Conexión larga
3 Breve descripción del modo MVC y el modo MVT
4 Breve descripción del ciclo de vida de la solicitud de Django
5 Breve descripción de lo que es FBV y CBV
6 Hable sobre su comprensión de ORM
7 Proceso del componente de autenticación Rest_framework
8 Qué es el middleware y una breve descripción de it Function
9 ciclo de vida del middleware django
10 cómo escribir SQL nativo en django
11 cómo usar django orm para crear datos en lotes

12 La diferencia entre el comando migrar y hacer migraciones
14 ¿Cuál es la forma de respuesta de la vista común?
15 Clasificación de los códigos de estado comunes en las respuestas HTTP
16 ¿Qué es el principio de coincidencia de rutas?
17 ¿Cuáles son los tipos de sistemas de caché
18 ¿Cuál es la forma común de resolver dominios cruzados?
19 ¿Cuál es la función de la señal?

20 La herencia del modelo de Django tiene varias formas, ¿ cuáles
son ?, cómo leer y guardar la sesión en Django, cuál es el mecanismo operativo de toda la sesión 25 Describe brevemente el proceso de ejecución de Django para solicitudes http 25 En Django, cuando el usuario inicia sesión en el servidor A e ingresa al estado de inicio de sesión, ¿qué sucederá la próxima vez que el usuario sea enviado al servidor B por nginx? Afecta 26 ¿Cómo maneja Django las solicitudes entre dominios? ¿Qué es la ejecución perezosa? 28 ¿Cuáles son los filtros de lista devueltos por el conjunto de consultas ? 29 ¿Cómo obtener todas las direcciones URL registradas en django urlpatterns? 31 ¿Cuál es la diferencia entre la ruta en django2.0 y la url en django1.xx? 32 ¿Cuál es el papel del nombre y el espacio de nombres en los patrones de URL? ¿Como lo usas? 34 ¿Cómo establecer una clave principal para un campo? 35 ¿Cómo configurar un diccionario con valores enumerados? 36 ¿Cuál es la diferencia entre auto_now y auto_now_add en el tipo DateTimeField 37 ¿Cuál es la diferencia entre valores() y valores_lista()? 38 ¿Cuál es la diferencia entre selected_related y prefetch_related?

















39 Al eliminar una clave externa, cómo eliminar la relación correspondiente con ella
40 ¿Qué son los campos de metainformación en la clase Meta?
41 ¿Cómo insertar datos en una tabla asociada de muchos a muchos? ¿Cómo borrar datos? ¿Cómo actualizar los datos?
42 En la relación M2M de django, ¿cómo generar manualmente la tercera tabla?
43 En Django, ¿de cuántas formas responde el servidor al cliente? ¿Qué son?
44 En la función de vista, ¿cuáles son los decoradores de validación más utilizados?
45 ¿Cómo agregar almacenamiento en caché a una función de vista?
46 ¿Cuál es la esencia del framework web?
47 Crear el proyecto Django, la aplicación Django y ejecutar comandos
48 Mecanismo de implementación de csrf en django 49
Estructura de directorios de la aplicación Django
50 Varias formas en que Django obtiene datos de solicitud de usuario
51 Describir la etiqueta simple_tag personalizada
52 Qué es una cookie, cómo obtenerla , configuración de cookies
53 Qué es sesión, comparación con cookies, configuración, obtención y borrado de sesiones
54 Qué es CSRF y cómo prevenirlo
55 La diferencia entre solicitud de obtención y solicitud posterior
56 Cómo se diseña la estructura de tablas del sistema de gestión de bibliotecas ?
57 Distinción entre WSGI / uwsgi / uWSGI
59 Explique espacios en blanco y nulos
60 QueryDict y diferencia de dictado
61 Cuénteme sobre su comprensión de las especificaciones tranquilas.
62 Django en sí proporciona un servidor de ejecución, ¿por qué no se puede usar para la implementación? 
63 ¿Cuál es el núcleo de Tornado? 
64 ¿Cómo se implementa la redirección de Django? ¿Qué código de estado se utiliza? 
65 Cómo cargar datos de inicialización en Django 
66 Describa brevemente el mecanismo de almacenamiento en caché (incorporado) en Django

Volver arriba
1 Enumere los métodos de solicitud comunes en solicitudes Http
Métodos de solicitud HTTP:
El protocolo HTTP/1.1 define ocho métodos (a veces llamados "acciones") para indicar los diferentes métodos de operación de los recursos especificados por Request-URL

Nota:
1) El nombre del método distingue entre mayúsculas y minúsculas. Cuando el recurso objetivo de una solicitud no admite el método de solicitud correspondiente, el servidor debe devolver el código de estado 405 (Método no permitido); cuando el servidor no sabe o no admite el método de solicitud correspondiente Al solicitar un método, se debe devolver un código de estado de 501 (No implementado).
2) El servidor HTTP debe implementar al menos los métodos GET y HEAD/POST, y otros métodos son opcionales. Además de los métodos anteriores, un servidor HTTP específico admite métodos personalizados extendidos.
CONSEGUIR

Hacer una solicitud a un recurso de ruta específico

Nota: El método GET no debe usarse en operaciones que produzcan "efectos secundarios", como en WebApplication, una de las razones es que las arañas web pueden acceder aleatoriamente a GET, etc. Funciones de solicitud de obtención correspondientes en Loadrunner: web_link y web_url

  POST

Envíe datos al recurso de ruta especificado para procesar solicitudes (generalmente se usa para enviar formularios o cargar archivos)

Los datos están contenidos en el cuerpo de la solicitud, y las solicitudes POST pueden resultar en la creación de nuevos recursos y/o la modificación de recursos existentes. Función de solicitud POST correspondiente en Loadrunner: web_submit_data, web_submit_form

OPTIONS               

Devuelve los métodos de solicitud HTTP admitidos por el servidor para un recurso específico

Permite al cliente ver el rendimiento del servidor y también puede probar la funcionalidad del servidor enviando una solicitud '*' al servidor web

 HEAD

Solicite al servidor una respuesta coherente con la solicitud GET, pero no se devolverá el cuerpo de la respuesta.

Este método permite obtener la metainformación contenida en el encabezado de la respuesta sin tener que transmitir todo el contenido de la respuesta.

 PUT

Los datos enviados desde el cliente al servidor reemplazan el contenido del documento especificado

 DELETE 

Solicitar al servidor que elimine la página especificada

 TRACE

Hacer eco de la solicitud recibida por el servidor, principalmente para pruebas o diagnóstico

 CONNECT

Reservado en el protocolo HTTP/1.1 para servicios de proxy que pueden cambiar las conexiones a las canalizaciones

Vuelva al principio
2 y hable sobre su comprensión del protocolo HTTP. 1.1 Conexión persistente
HTTP es un protocolo orientado a objetos perteneciente a la capa de aplicación.El
protocolo HTTP trabaja sobre la arquitectura cliente-servidor. Como cliente HTTP, el navegador envía todas las solicitudes al servidor HTTP, es decir, al servidor WEB, a través de la URL. El servidor web envía información de respuesta al cliente de acuerdo con la solicitud recibida.
Basado en
la secuencia de comunicación TCP/IP entre las dos partes, y los pasos que deben procesarse que se muestran en la página web, y así sucesivamente. Una colección de protocolos relacionados con Internet como este se conoce colectivamente como TCP/IP. El protocolo http es un protocolo de capa de aplicación basado en el protocolo TCP/IP.
Basado en el modo de solicitud-respuesta,
el protocolo HTTP estipula que la solicitud se envía desde el cliente y, finalmente, el servidor responde a la solicitud y devuelve el
almacenamiento sin
estado.HTTP es un protocolo sin estado que no guarda el estado. El protocolo HTTP en sí mismo no guarda el estado de comunicación entre la solicitud y la respuesta. Es decir, a nivel HTTP, el protocolo no persiste en las solicitudes o respuestas enviadas.
Usando el protocolo HTTP, siempre que se envíe una nueva solicitud, se generará una nueva respuesta correspondiente. El protocolo en sí no retiene información sobre todos los mensajes de solicitud o respuesta anteriores. Esto es para procesar una gran cantidad de transacciones más rápido y garantizar la escalabilidad del protocolo, y el protocolo HTTP está diseñado deliberadamente para ser tan simple. Sin embargo, con el desarrollo continuo de la Web, existen procesos comerciales cada vez más difíciles debido a la apatridia. Por ejemplo, si un usuario inicia sesión en un sitio web de compras, incluso después de pasar a otras páginas del sitio, debe poder continuar iniciando sesión. Para este ejemplo, para poder comprender quién envió la solicitud, el sitio web debe guardar el estado del usuario. Aunque HTTP/1.1 es un protocolo sin estado, para lograr la función de mantenimiento de estado deseada, se introduce la tecnología de cookies. Con cookies y luego usando el protocolo HTTP para comunicarse, se puede administrar el estado.

Volver arriba
3 Describa brevemente el modo MVC y el modo MVT
El llamado MVC consiste en dividir la aplicación Web en tres capas: modelo (M), controlador© y vista (V), y se conectan en un complemento juntos, el modelo es responsable del mapeo (ORM) de objetos comerciales y bases de datos, la vista es responsable de la interacción con los usuarios (páginas) y el controlador acepta la entrada del usuario para llamar al modelo y la vista para completar el solicitud del usuario

El modo MTV de MTV
Django es esencialmente el mismo que MVC, y también mantiene una relación débilmente acoplada entre los componentes, pero la definición es ligeramente diferente. MTV de Django es el valor:

M significa Model (Modelo): Responsable del mapeo relacional (ORM) de objetos comerciales y bases de datos.
T significa plantilla (Template): responsable de cómo mostrar la página al usuario (html).
V significa Vista (View): Responsable de la lógica comercial, y llame a Modelo y Plantilla cuando corresponda.
Además de las tres capas anteriores, también se necesita un distribuidor de URL. Su función es distribuir solicitudes de página de URL a diferentes vistas para su procesamiento, y luego View llama al modelo y la plantilla correspondientes. El modo de respuesta de MTV es el siguiente:

一般是用户通过浏览器向我们的服务器发起一个请求(request),这个请求回去访问视图函数,(如果不涉及到数据调用,那么这个时候视图函数返回一个模板也就是一个网页给用户),视图函数调用模型,模型去数据库查找数据,然后逐级返回,视图函数把返回的数据填充到模板中空格中,最后返回网页给用户。

Volver arriba
4 Describa brevemente el ciclo de vida de la solicitud de Django.
Generalmente, el usuario inicia una solicitud (solicitud) a nuestro servidor a través del navegador, y esta solicitud regresa para acceder a la función de vista (si no hay una llamada de datos involucrada, entonces la vista la función devuelve una plantilla en este momento, es decir, una página web para el usuario), la función de vista llama al modelo, el modelo va a la base de datos para buscar datos y luego regresa paso a paso, la función de vista completa los datos devueltos en los espacios en blanco en la plantilla y, finalmente, devuelve la página web al usuario.
#1.wsgi, encapsule la solicitud y transfiérala al marco web (Flask, Django)
#2.Middleware, verifique la solicitud o agregue otros datos relevantes al objeto de la solicitud, por ejemplo: csrf, request.session -
#3 Coincidencia de enrutamiento Coincide con diferentes funciones de vista de acuerdo con diferentes URL enviadas por el navegador
# 4. Función de vista, el procesamiento de la lógica de negocios en la función de vista puede involucrar: orm, plantillas => representación-
# 5. Middleware, para la respuesta Los datos es procesado.
#6.wsgi, envíe el contenido de la respuesta al navegador.

Volver arriba
Para obtener más información, vaya a la respuesta pública de WeChat: preguntas de la entrevista de django
inserte la descripción de la imagen aquí

Hay respuestas detalladas
Para obtener más información, vaya a la respuesta pública de WeChat: preguntas de la entrevista de django
Para obtener más información, vaya a la respuesta pública de WeChat: preguntas de la entrevista de django
Para obtener más información, vaya a la respuesta pública de WeChat: preguntas de la entrevista de django
——— ————————— —————
Declaración de derechos de autor: este artículo es un artículo original del blogger de CSDN "BigC Brother", siguiendo el acuerdo de derechos de autor CC 4.0 BY-SA, adjunte el enlace de la fuente original y esta declaración para la reimpresión.
Enlace original: https://blog.csdn.net/weixin_43063753/article/details/85559540

Supongo que te gusta

Origin blog.csdn.net/bruce_van/article/details/103841983
Recomendado
Clasificación