Maison  >  Article  >  développement back-end  >  Recommandation de ressources de didacticiel vidéo pratique du blog Laravel5.2

Recommandation de ressources de didacticiel vidéo pratique du blog Laravel5.2

黄舟
黄舟original
2017-08-31 13:41:121657parcourir

Laravel est un framework de développement Web PHP simple et élégant (PHP Web Framework). Il peut vous libérer des codes désordonnés comme les nouilles ; il peut vous aider à créer une application réseau parfaite, et chaque ligne de code peut être concise et expressive. Par conséquent, nous avons rassemblé le « Tutoriel vidéo pratique du blog Laravel5.2 », qui est un ensemble de didacticiels de développement pratiques de Laravel5.2 axés sur le combat réel du projet, qui constitue une véritable introduction à la maîtrise. J'espère que cela pourra aider tout le monde à mieux apprendre le framework Laravel.

Recommandation de ressources de didacticiel vidéo pratique du blog Laravel5.2

Adresse de lecture du cours : http://www.php.cn/course/283.html

Le style d'enseignement du professeur :

Les cours sont conviviaux et naturels, sans prétention, ni prétentieux ni délibérément exagérés, mais parlent avec éloquence et prudence, entre enseignants et étudiants Dans une atmosphère d'égalité, la collaboration et l'harmonie, des échanges émotionnels silencieux sont réalisés, et le désir et l'exploration des connaissances sont intégrés dans des situations d'enseignement simples et réelles. Les étudiants acquièrent des connaissances grâce à une réflexion calme et une approbation silencieuse

La partie la plus difficile. dans cette vidéo se trouve le middleware HTTP :

-- Qu'est-ce que le middleware ?
1. Pourquoi un middleware est nécessaire

La technologie informatique se développe rapidement. Du point de vue de la technologie matérielle, les vitesses du processeur sont de plus en plus élevées et les capacités de traitement sont de plus en plus fortes ; du point de vue de la technologie logicielle, l'échelle des applications continue de s'étendre, en particulier l'émergence d'Internet et du WWW, ce qui rend la portée des applications informatiques est plus large et les applications nombreuses. Le programme doit fonctionner sur des plates-formes hétérogènes dans un environnement réseau. Tout cela met en avant de nouvelles exigences pour une nouvelle génération de développement logiciel. Dans cet environnement hétérogène distribué, il existe généralement plusieurs plates-formes système matérielles (telles que des PC, des postes de travail, des mini-ordinateurs, etc.) et une variété de logiciels système (tels que différents systèmes d'exploitation, bases de données, etc.) sur ces plates-formes matérielles. compilateur, etc.), ainsi qu'une variété d'interfaces utilisateur avec des styles différents. Ces plates-formes de systèmes matériels peuvent également utiliser différents protocoles réseau et architectures réseau pour se connecter. Comment intégrer ces systèmes et développer de nouvelles applications est un problème très réel et difficile.

2 Qu'est-ce qu'un middleware

Afin de résoudre le problème de l'hétérogénéité distribuée, les gens ont proposé le concept de middleware. Le middleware est un service commun situé entre la plate-forme (matériel et système d'exploitation) et l'application, comme le montre la figure 1. Ces services disposent d'interfaces de programme et de protocoles standard. Pour différents systèmes d'exploitation et plates-formes matérielles, ils peuvent avoir plusieurs implémentations conformes aux spécifications d'interface et de protocole.

Il peut être difficile de donner une définition stricte du middleware, mais le middleware doit avoir les caractéristiques suivantes :

Répondre aux besoins d'un grand nombre d'applications
Fonctionner sur une variété de plates-formes matérielles et de systèmes d'exploitation
Prend en charge l'informatique distribuée, fournissant une interaction transparente entre les applications ou les services sur les réseaux, le matériel et les plates-formes de système d'exploitation.
Prend en charge les protocoles standard
Prend en charge les interfaces standard

Étant donné que les interfaces standard sont importantes pour la portabilité et les protocoles standard. Compte tenu de l’importance de l’interopérabilité, les middlewares sont devenus un élément majeur de nombreux efforts de normalisation. Pour le développement de logiciels d'application, les middlewares sont bien plus importants que les systèmes d'exploitation et les services réseau. L'interface de programme fournie par les middlewares définit un environnement d'application de haut niveau relativement stable, quelle que soit la manière dont le matériel informatique et les logiciels système sous-jacents sont mis à jour. le middleware est mis à niveau et mis à jour, et conserve la définition de l'interface externe du middleware inchangée, le logiciel d'application ne nécessite presque aucune modification, protégeant ainsi l'investissement important de l'entreprise dans le développement et la maintenance des logiciels d'application.

3. Classification des principaux middlewares

Les middlewares couvrent une très large gamme et une variété de produits middleware distinctifs ont émergé pour différents besoins d'application. Mais jusqu’à présent, il n’existe pas de définition plus précise du middleware. Par conséquent, la classification des middlewares sera différente selon les perspectives ou les niveaux. Étant donné que le middleware doit protéger les systèmes d'exploitation et les protocoles réseau hétérogènes dans un environnement distribué, il doit être capable de fournir des services de communication dans un environnement distribué. Nous appelons ce service de communication une plate-forme. En fonction des différents objectifs et mécanismes de mise en œuvre, nous divisons la plateforme dans les catégories principales suivantes :

Appel de procédure à distance (appel de procédure à distance)
Middleware orienté message (Middleware orienté message)
Objet Courtiers de demandes d'objets

Ils peuvent fournir différentes formes de services de communication, notamment la synchronisation, la mise en file d'attente, la publication d'abonnements, la diffusion, etc. En plus de ces plates-formes de communication de base, divers cadres peuvent être construits pour fournir des services dans différents domaines. pour les applications, telles que le moniteur de traitement des transactions, l'accès aux données distribuées, le gestionnaire de transactions d'objets OTM, etc. La plate-forme protège les différences entre les plates-formes hétérogènes pour les applications de couche supérieure, et le cadre qui y est défini définit la structure du système, les composants de service standard, etc. des applications dans les domaines correspondants. Les utilisateurs n'ont qu'à indiquer au cadre les événements qui les préoccupent. , puis fournissez le traitement de ces événements. Lorsqu'un événement se produit, le framework appelle le code de l'utilisateur. Le code utilisateur n'a pas besoin d'appeler le framework, et les programmes utilisateur n'ont pas besoin de se soucier de la structure du framework, du processus d'exécution, des appels aux API au niveau du système, etc., qui sont tous complétés par le framework. Par conséquent, les applications développées sur la base d'un middleware ont une bonne évolutivité, une bonne gérabilité, une haute disponibilité et une bonne portabilité.

Ce qui suit est une brève introduction à plusieurs principaux types de middleware.

1. Appel de procédure à distance

L'appel de procédure à distance est une méthode de traitement d'application distribuée largement utilisée. Une application utilise RPC pour exécuter « à distance » un processus situé dans un espace d'adressage différent et a le même effet que l'exécution d'un appel local. En fait, une application RPC est divisée en deux parties : le serveur et le client. Le serveur fournit une ou plusieurs procédures distantes ; le client effectue des appels distants vers le serveur. Le serveur et le client peuvent être situés sur le même ordinateur, ou sur des ordinateurs différents, ou même fonctionner sur des systèmes d'exploitation différents. Ils communiquent via le réseau. Les stubs correspondants et la prise en charge du runtime fournissent des services de conversion de données et de communication, protégeant ainsi différents systèmes d'exploitation et protocoles réseau. Ici, la communication RPC est synchrone. Les threads peuvent être utilisés pour effectuer des appels asynchrones.

Dans le modèle RPC, tant que le client et le serveur disposent de l'interface RPC correspondante et prennent en charge l'exécution de RPC, ils peuvent effectuer l'interopération correspondante sans être limités à un serveur spécifique. Par conséquent, RPC fournit un support solide pour l’informatique distribuée client/serveur. Dans le même temps, l'appel de procédure à distance RPC fournit un accès au service basé sur le processus. Le client et le serveur sont directement connectés, et il n'y a aucun organisme intermédiaire pour traiter la demande, il présente donc également certaines limites. Par exemple, RPC nécessite généralement certains détails du réseau pour localiser le serveur ; lorsque le client fait une demande, le serveur doit être actif, etc.

2. Middleware orienté message

MOM fait référence à l'utilisation de mécanismes de transmission de messages efficaces et fiables pour l'échange de données indépendant de la plate-forme et à l'intégration de systèmes distribués basés sur la communication de données. En fournissant un modèle de transmission de messages et de mise en file d'attente de messages, il étend la communication inter-processus dans un environnement distribué et prend en charge plusieurs protocoles de communication, langages, applications, plates-formes matérielles et logicielles. Les produits middleware MOM actuellement populaires incluent MQSeries d'IBM, MessageQ de BEA, etc. La technologie de messagerie et de file d'attente présente les trois caractéristiques principales suivantes :

Les programmes de communication peuvent s'exécuter à des moments différents. Les programmes ne se parlent pas directement sur le réseau, mais placent indirectement les messages dans la file d'attente des messages, car il y en a. pas de lien direct entre les programmes. Ils ne doivent donc pas courir en même temps. Le programme cible n'a même pas besoin d'être en cours d'exécution lorsqu'un message est placé dans la file d'attente appropriée ; même si le programme cible est en cours d'exécution, il n'est pas censé traiter le message immédiatement.

Il n'y a aucune contrainte sur la structure des programmes d'application. Dans des scénarios d'application complexes, les programmes de communication peuvent non seulement avoir une relation un-à-un, mais également des méthodes un-à-plusieurs et plusieurs-à-un, ou même une combinaison de celles-ci. les méthodes ci-dessus. La construction de multiples méthodes de communication n’augmente pas la complexité de l’application.

Les programmes sont isolés de la complexité du réseau

Les programmes placent les messages dans les files d'attente de messages ou retirent les messages des files d'attente de messages pour la communication et toutes les activités associées à cela, telles que la maintenance des files d'attente de messages, le maintien de la relation entre les programmes et les files d'attente, la gestion des redémarrages du réseau et le déplacement des messages à travers le réseau sont les tâches de MOM. Les programmes ne communiquent pas directement avec d'autres programmes et n'impliquent pas la complexité de la communication réseau.

3. Proxy de demande d'objet

Avec le développement de la technologie objet et de la technologie informatique distribuée, les deux se combinent pour former l'informatique objet distribuée, qui est devenue la direction dominante de la technologie logicielle actuelle. Fin 1990, l'Object Management Group OMG a lancé pour la première fois l'architecture de gestion d'objets OMA (Object Management Architecture). L'Object Request Broker est le composant central de ce modèle. Son rôle est de fournir un cadre de communication permettant de transmettre de manière transparente des requêtes d'objets dans des environnements informatiques distribués hétérogènes. La spécification CORBA inclut toutes les interfaces standard d'ORB. CORBA 1.1, lancé en 1991, a défini le langage de description d'interface OMG IDL et l'API qui prend en charge les objets Client/Serveur pour interagir sur des ORB spécifiques. La spécification CORBA 2.0 décrit l'interopérabilité entre les ORB fournis par différents fournisseurs.

Object Request Broker (ORB) est un bus d'objets. Il est au cœur de la spécification CORBA. Il définit le mécanisme de base permettant aux objets d'envoyer des requêtes et de recevoir des réponses de manière transparente dans des environnements hétérogènes. client/serveur entre objets. ORB permet aux objets d'adresser de manière transparente des requêtes à d'autres objets ou de recevoir des réponses d'autres objets, qui peuvent être situés localement ou sur une machine distante. ORB intercepte les appels de requêtes et est chargé de trouver les objets pouvant implémenter les requêtes, de transmettre les paramètres, d'appeler les méthodes correspondantes, de renvoyer les résultats, etc. L'objet client ne connaît pas le mécanisme de communication avec l'objet serveur, d'activation ou de stockage de l'objet serveur, et n'a pas non plus besoin de savoir où se trouve l'objet serveur, dans quel langage il est implémenté, quel système d'exploitation est utilisé ou autre. composants du système qui ne font pas partie de l’interface objet.

Il est à noter que les rôles client et serveur ne servent qu'à coordonner l'interaction entre les objets. Selon l'occasion correspondante, l'objet sur l'ORB peut être un client, un serveur, voire les deux. Lorsqu'un objet fait une requête, il est dans le rôle client ; lorsqu'il reçoit une requête, il est dans le rôle serveur. La plupart des objets jouent à la fois des rôles de client et de serveur. De plus, étant donné que ORB est responsable de la transmission des requêtes d'objets et de la gestion du serveur, il n'y a pas de connexion directe entre le client et le serveur. Par conséquent, par rapport à la structure client/serveur simple prise en charge par RPC, ORB peut prendre en charge des structures plus complexes.

4. Surveillance du traitement des transactions

Les moniteurs de traitement des transactions sont apparus pour la première fois sur les mainframes, leur fournissant un environnement d'exploitation fiable prenant en charge le traitement des transactions à grande échelle. Avec le développement de la technologie informatique distribuée, les systèmes d'applications distribués ont mis en avant des demandes de traitement de transactions à grande échelle, comme le traitement d'un grand nombre de transactions clés dans les activités commerciales. La surveillance du traitement des transactions s'effectue entre le client et le serveur et effectue la gestion et la coordination des transactions, l'équilibrage de charge, la reprise après panne, etc. pour améliorer les performances globales du système. Il peut être considéré comme le « système d’exploitation » pour les applications de traitement des transactions. De manière générale, la surveillance du traitement des transactions a les fonctions suivantes :

Gestion des processus, notamment le démarrage du processus serveur, l'attribution de tâches, le suivi de son exécution et l'équilibrage de la charge.
La gestion des transactions garantit l'atomicité, la cohérence, l'indépendance et la pérennité du traitement des transactions sous sa supervision.
La gestion de la communication fournit une variété de mécanismes de communication entre le client et le serveur, notamment la réponse aux demandes, la session, la file d'attente, la publication et la diffusion d'abonnements, etc.
La surveillance du traitement des transactions peut fournir des services à un grand nombre de clients, tels que les systèmes de billetterie d'avion. Si le serveur alloue les ressources dont il a besoin à chaque client, le serveur sera submergé (comme le montre la figure 2). Mais en réalité, tous les clients n’ont pas besoin de demander des services en même temps, et lorsqu’un client demande un service, il espère obtenir une réponse rapide. La surveillance du traitement des transactions fournit un ensemble de services au-dessus du système d'exploitation, gère les demandes des clients et leur alloue les processus de service correspondants, afin que le serveur puisse fournir efficacement des services à des clients à grande échelle disposant de ressources système limitées.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn