Je me demandais si quelqu'un peut comparer/contraste les différences entre frontend, backend, et middleware ("milieu de gamme"?) de façon succincte.
Existe-il des cas où ils se chevauchent? Existe-il des cas où ils DOIVENT se chevaucher, et frontend/backend ne peuvent pas être séparés? En termes de goulots d'étranglement, dont l'extrémité est associée avec le type de goulots d'étranglement?
Voici une ventilation:
Niveau frontal -> Interface Utilisateur de la couche généralement constitués d'un mélange de HTML, Javascript, CSS, Flash, et divers code côté serveur comme ASP.Net classique, ASP, PHP, etc. Pensez à cela comme étant plus proche de l'utilisateur en termes de code.
Middleware, de niveau intermédiaire -> Un niveau du dos, généralement désignée comme la "plomberie" partie d'un système. Java et C# sont des langages communs pour l'écriture de cette partie qui pourrait être considéré comme de la colle entre l'INTERFACE utilisateur et les données et peut être webservices ou WCF composants ou d'autres composants SOA peut-être.
Niveau -> Bases de données et d'autres magasins de données sont généralement à ce niveau. Oracle, MS-SQL, MySQL, SAP, et divers hors-the-shelf morceaux de logiciel viennent à l'esprit pour ce morceau de logiciel qui est le traitement final des données.
Chevauchement peut exister entre l'un de ces que vous pourriez avoir tout versé en une seule couche comme un ASP.Net site web qui utilise le built-in fonctionnalité AJAX qui génère du Javascript tout le code derrière peut contenir des commandes de base de données du code derrière contiennent à la fois moyen et fin de niveaux. Alternativement, on peut utiliser VBScript pour agir à titre de toutes les couches à l'aide d'ADO objets et de la fusion de trois niveaux en un seul.
De même, le middleware et soit à l'avant ou à l'arrière de fin peuvent être combinés dans certains cas.
Les goulots d'étranglement ont généralement plusieurs niveaux:
1) la Base de données ou de traitement en arrière-plan -> Cela peut varier de la paie ou de vente ou d'autres tâches où le débit de la base de données s'enlise choses vers le bas.
2) Middleware les goulots d'étranglement -> Ce serait le cas si certains de service web peut être de frapper la capacité, mais l'avant et l'arrière extrémités ont de la bande passante pour gérer plus de trafic. Sinon, il peut être un serveur qui fait partie d'un système qui n'est pas tout à fait la partie de l'INTERFACE utilisateur ou les données brutes qui peut être un goulot d'étranglement en utilisant quelque chose comme Biztalk ou MSMQ.
3) Avant la fin de l'étranglement -> Cela pourrait client ou côté serveur des questions. Par exemple, si vous avez pris un ordinateur bas de gamme et qu'il avait chargement d'une page web qui se composait d'un grand nombre de données en cours de téléchargement, le client pourrait être l'endroit où le goulot d'étranglement est. De même, le serveur pourrait être la file d'attente des demandes si il est martelé avec des requêtes comme quoi Amazon.com ou d'autres haut-trafic de sites web peuvent obtenir à la fois.
Certains de ce qui est sujet à interprétation, de sorte qu'il n'est pas parfait, par tout moyen et YMMV.
EDIT: une Chose à considérer est que certains systèmes peuvent avoir plusieurs front-end ou back-end. Par exemple, un système de gestion de contenu aura probablement une façon pour les visiteurs du site pour afficher le contenu est un front-end mais que penser de la façon dont les éditeurs de contenu sont en mesure de modifier les données sur le site? La capacité de tirer de ces données pourrait être considérée comme une fin, car il est un composant de l'INTERFACE utilisateur, ou il pourrait être considéré comme un back-end car il est utilisé par les utilisateurs internes plutôt que le grand public peut consulter le site. Ainsi, il y a quelque chose à dire pour le contexte ici.
Généralement parlant, les gens se réfèrent à une demande de la couche de présentation comme à son extrémité avant, sa couche de persistance (base de données, généralement) que le back-end, et tout ce qui entre comme couche intermédiaire. Cet ensemble d'idées est souvent désigné comme l'architecture 3 tiers. Ils vous permettent de séparer votre demande dans les plus facilement compréhensibles (et vérifiables!) morceaux; vous pouvez également la réutilisation de palier inférieur code plus facilement dans les niveaux supérieurs.
Le code qui fait partie de quel niveau est quelque peu subjective; les graphistes ont tendance à penser à tout ce qui n'est pas la présentation que l'extrémité arrière, la base de données des personnes pour penser à tout en face de la base de données de l'extrémité avant, et ainsi de suite.
Toutes les applications ne doivent être séparées de cette façon, si. C'est certainement plus de travail pour avoir 3 sous-projets distincts, qu'il est juste d'ouvrir index.php et obtenir la fissuration; selon (1) depuis combien de temps vous attendez-vous à devoir maintenir l'application (2) le degré de complexité de vous attendre à l'application d'obtenir, vous pouvez renoncer à la complexité.
Il y a en fait 3 questions dans votre question :
Ce JB King a décrit est correct, mais il est un particulier, version simple, où, en fait, il a reproduit l'avant, au milieu et bacn à une couche MVC. Il a tracé les M à l'arrière, V à l'avant, et C à la moyenne.
Pour beaucoup de gens, il est tout simplement parfait, comme ils viennent de le vilain monde où même MVC n'a pas été appliquée, et vous pourrait avoir un effet direct DB appels en vue.
Toutefois, dans la vraie, applications web complexes, vous avez en effet deux ou trois couches différentes, appelé front, middle et back. Chacun d'eux peut avoir une base de données associée et un contrôleur.
Le front-end sera visible par l'utilisateur final. Il ne doit pas être confondu avec le front-office, qui est l'INTERFACE utilisateur pour les paramètres et de l'administration de l'avant. Le front-end sera généralement une sorte de CMS ou de la Plateforme de e-commerce (Magento, etc.)
Le milieu-fin n'est pas obligatoire et où les logiques d'entreprise. Il sera basé sur un GIP, un outil de MDM, ou une sorte de base de données personnalisée où vous enrichir de vos produits ou de vos articles (CMS). Ce sera aussi l'endroit où vous le code des fonctions de l'entreprise, qui doivent être partagées entre les différentes interfaces (par exemple entre le PC frontend et l'API basée sur l'application mobile). Parfois, un ESB ou d'un outil comme ActiveMQ sera votre intermédiaire
Le back-end sera une 3ème couche, surrouding votre base de données source ou de votre ERP. Il peut être juste l'API wrting à et la lecture à partir de votre ERP. Il peut être votre fournisseur DB, si vous faites du e-commerce. En fait, cela dépend vraiment de projets web, mais il est toujours d'un référentiel central. Il sera accessible soit par le biais d'un DB d'appel, par le biais d'une API, ou une Hibernate couche, ou un plein de fonctionnalités d'applications back-end
Cette description signifie que répondre les 2 autres questions n'est pas possible dans ce fil, comme des goulots d'étranglement vraiment dépend de ce que votre 3 se termine contenir : ce que JB King a écrit reste vrai pour de simples architectures MVC
au moment où la question a été posée (il y a 5 ans), peut-être le modèle MVC n'était pas encore si largement adopté. Maintenant, il n'y a absolument aucune raison pour laquelle le modèle MVC ne serait pas suivi et une vue serait liée à l'DB appels. Si vous lisez la question "existe-il des cas où ils DOIVENT se chevaucher, et frontend/backend ne peuvent pas être séparés?" dans un sens plus large, avec 3 différents composants, puis il y a des moments où le 3 couches de l'architecture est inutile de cours. Pensez à un simple blog personnel, vous n'aurez pas besoin de tirer des données extérieures ou des sondage RabbitMQ files d'attente.
En termes de réseau et de sécurité, le Backend est de loin le plus (devrait être) sûr nœud.
Le milieu-fin de partie, généralement un serveur web, sera en quelque sorte à l'état sauvage et de couper à de nombreux égards, à partir d'un réseau de la société. Le milieu-fin de nœud est habituellement placé dans la DMZ et segmenté à partir du réseau avec les paramètres du pare-feu. La plupart du code côté serveur d'analyse de pages web est géré sur le milieu-fin de serveur web.
Arriver à l'arrière-plan moyen passant par le moyen-end, qui a soigneusement ensemble de règles permettant d'/refuse l'accès à l'essentiel nummies qui sont stockées dans la base de données (backend) du serveur.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
