J'ai écrit des logiciels depuis plusieurs décennies maintenant et ces jours-ci, tout est web.
Avant le Web, nous avons eu des applications serveur client qui étaient essentiellement des applications client épaisses qui ont parlé directement à la base de données. Ils avaient des inconvénients, tels que le déploiement étant encombrant, n'a pas échoué parce que DB a manipulé tout le trafic. Bien sûr, la distribution des applications était limitée à être sur un bureau sur un réseau d'entreprise. Les avantages pour ces applications étaient qu'ils avaient moins de couches et ont été rapides à développer.
Il y a des moments où les exigences appellent une application derrière un pare-feu avec une base de données dédiée et une quantité relativement petite de clients. Je suggère (parfois sur Stackoverflow) l'ancienne architecture de type client / serveur et tout le monde me regarde comme si j'ai 3 jambes et 6 bras.
avec des technologies modernes permettant des déploiements automatiques d'applications et des outils que nous avons aujourd'hui. Y a-t-il une raison pour laquelle cette technologie n'est pas viable? Est-ce que la nouvelle génération de développeurs connaît uniquement des trucs Web?
4 Réponses :
Je suis sûr que les clients épais sont toujours développés, même aujourd'hui.
Ayant dit que, choisir une architecture Web, il ne s'agit pas de la "nouvelle génération de développeurs" uniquement en sachant que des trucs Web, vous obtenez beaucoup d'avantages si vous pouvez rendre votre application Web:
Mais à la fin de la journée, tout est sur le bon outil pour le travail. Les applications Web ne vous aident pas lorsque vous souhaitez écrire des plugins pour Office (Word, Outlook, etc.), ils ne vous aident pas si vous devez contrôler le matériel personnalisé (terminaux de point de vente, etc., bien que vous puissiez écrire cela dans le serveur dans certains cas ...), et probablement quelques autres cas aussi.
Je peux penser à au moins deux marchés de grands ish où le serveur client est toujours important:
Nous avons des applications flexibles qui communiquent avec des services Web basés sur XML qui sont assez proches des applications de serveur client de Old School. Mais plutôt que d'utiliser SQL, ils parlent une langue XML personnalisée et rendu des réponses de savon.
Ensuite, vous devez programmer, entretenir et administrer tout un niveau moyen. XML est encombrant. C'est un outil pour de nombreuses applications, mais j'essaie de convaincre les gens que nous sommes éloignés de la simplicité, où parfois une solution plus simple est toujours meilleure. J'écris également des applications GWT ainsi que des applications Web, donc je comprends la mécanique.
Nous développons et déployons actuellement de nombreuses applications client / serveur chaque année. Le développement est simple et automatisé. Nous ne nous limitons pas aux technologies de la base de données que nous sommes en mesure de déployer. Les déploiements client / serveur sont plus rapides pour les calculs, forment des mises à jour et des rapports. Les applications Web / Cloud basées sur le cloud sont moins sensibles qu'une application exécutée sur une station cliente (client épais).
Ceci est dû à la distribution de la charge de la CPU. Alors qu'une application côté serveur nécessite que le serveur exécute tous les calculs, le côté client peut exécuter ceci sur la machine locale. Comme tout système devient plus complexe, les moments où un utilisateur doit attendre des augmentations de résultats. Ces moments de temps des employés sont plus chers car ils impliquent plus d'employés rémunérés. Ces moments s'ajoutent au sein d'une organisation comme une grande "heure de l'homme" sur une année.
Les problèmes des mises à jour sont résolus dans notre ensemble d'outils de développement. Tout comme lorsque vous pouvez ouvrir votre navigateur préféré, il remarque que la version que vous utilisez n'est pas la plus récente que nous intégrons le même processus dans nos applications client / serveur. En fait, nous ne leur donnons pas le choix de mettre à jour. Étant donné que les mises à jour peuvent, plusieurs fois, nécessitent des modifications de la base de données, nous forcons la mise à jour de l'utilisateur avant que l'utilisateur soit autorisé à exécuter le logiciel.
Pour améliorer la visibilité des informations contenues avec nos systèmes client / serveur personnalisés, nous proposons des sites Web développés personnalisés contenant des applications spécifiques telles que l'envoi de champs ou l'intégration du forum de support client dans les applications client / serveur de bureau. De mon point de vue, je vois une intégration complète du serveur client et des applications Web réactives prenant une meilleure position dans les années à venir.
Quoi, jamais entendu parler des applications d'accès?
Hey, tu es des enfants! Descendre ma pelouse!
Dans ces jours-ci, je me suis étouffé à chaque fois que quelqu'un dit que les navigateurs sont des clients minces ... ils n'ont pas choisi la liste des addons dans mon FF ...
Je aspirai pour les jours de client / serveur, mais tous mes clients veulent des applications Webby. J'ai eu une très bonne période de cela il y a quelques semaines sur une application WPF où je disposais d'un État sur le client qui a rendu la vie si douce, mais même qui a été convertie en ASP.Net après que le MD ait voulu qu'il voulait travailler sur son nouvel iPad. :)