Comment appelleriez-vous physcially séparé Code UI / BL en solution ASP.NET?

Question

Chapitre 19: physique et déploiement Tiers sur MSDN décrit « Distribuée déploiement »(voir la figure 2). Tout va bien.

Dans mon expérience, nous avons toujours déployé nos systèmes basés sur le Web selon ce qu'ils décrivent comme « Déploiement non distribuée » (figure 1). Je crois comprendre que dans le monde Microsoft le « Application Server » comme une chose distincte n'existe pas vraiment (comme dans le monde Java) parce qu'il est effectivement « cuit dans » à l'OS / Windows.

Alors, ma question est de savoir si vous deviez distribuer la logique et l'interface utilisateur d'affaires (BL) sur différents serveurs / niveaux, comment seraient-ils communiquer?

Je sais une réponse est d'utiliser une « couche de service » - quelles sont les alternatives? Comment feriez-vous fait cela? Que faudrait-il ressembler dans une perspective de code?

Answer 1

Tout d'abord. Ne pas le faire. Il suffit de ne pas. Vous êtes dans un monde de douleur. couches logiques et physiques sont des choses différentes. Séparation logique des niveaux d'application est une bonne idée. La séparation physique des niveaux d'application est le plus souvent une recette pour un désastre. S'il y a une bonne raison de déploiement (processeur de paiement partagé sur une autre boîte), bien sûr, allez-y. Vous pouvez utiliser les mécanismes standards que nous avons tous de connaître et à aimer - WCF, MSMQ, HTTP, ... Choisissez votre poison. Mais ne prenez pas les frais généraux et de la complexité pour le bien de la vie à un idéal mythique dans un livre blanc MSDN.

Answer 2

Serveurs d'applications ont été cuits comme une idée à la ration d'aide une ressource rare: pouvoir Compute au niveau intermédiaire. Cette idée est venue de la terre de l'ordinateur central, d'abord, où CPU était rare et cher, et donc beaucoup de temps et d'efforts et d'argent a été dépensé pour couper en dés le processeur central à divers utilisateurs, la charge de travail étranglant, en gardant la charge de la base de données, « passiver "transactions jusqu'à ce que la charge diminuée après les heures, et ainsi de suite. Dans ces jours, les gens ont dépensé des millions de dollars sur les logiciels piste gardé des transactions sur l'ordinateur central, de manière à pouvoir effectuer des « rétrofacturation » - coût interne comptable pour l'utilisation de l'ordinateur central dépen ive $. Oui, les gens ont dépensé l'argent des bateaux pleins afin qu'ils puissent faire la facturation aux services internes pour l'utilisation de l'ordinateur central.

La chose est, Intel (et plus tard AMD), Cisco (et al), EMC, Microsoft et Linux a rendu toute idée sans objet. Computing est devenu pas cher. Vraiment pas cher. Il est vraiment, vraiment, vraiment pas besoin de calcul de niveau intermédiaire de rationnement des ressources. Qu'est-ce qu'un serveur double-cpu pour aller ces jours-ci? Combien de ceux que vous pourriez déployer pour le salaire annuel d'un gars IT? Ceci est une inversion de l'ancienne économie de l'informatique mainframe, où le calcul était coûteux, ressource rare, et les gens étaient relativement (!!) pas cher. Maintenant, les gens sont la partie coûteuse et est Compute pas cher.

serveurs App, et toutes les cloches et de sifflets qu'ils ont pour restreindre l'accès à compute, ou parcellisation dehors, ou étranglant ou même « suivi » des opérations à des fins de refacturation .... ces choses ne sont pas nécessaires lorsque vous ont racks de serveurs AMD bon marché.

Une autre chose serveurs App ont été la base de données de bouclier charge de travail. Essentiellement, délester le travail à partir du serveur db. Le temps était, les développeurs ont mis la logique métier dans une procédure stockée et, boum, il y avait votre application. Mais il y avait des problèmes d'évolutivité avec cette approche. Maintenant, cependant, sont stockés procs rapide et efficace. les serveurs de base de données peuvent intensifier, à moindre coût. Les chances sont, vous ne l'avez pas des volumes de charge de travail haut-100 dans le monde qui ne peuvent pas être supportés sur le matériel Intel, avec une logique de procédure stockée.

Un problème majeur avec l'approche de procédure stockée cependant, est qu'il est encore assez dur à l'auteur stockées dans les langues procs traditionnels (Java, C #, VB, etc), et de les gérer. Oui, je sais VMs SQL CLR et Java géré par la DB. Mais ce ne sont pas des approches traditionnelles. En outre, la DB Admin ne pas comme jockeys de code déconner ses graphiques d'utilisation. Pour ces raisons, il y a encore une volonté de la logique métier d'écriture dans une langue distincte dédiée à cet effet. Et il y a encore un désir d'exécuter et de gérer cette logique sur les ressources de calcul dédiées. Mais ... un « serveur d'application » classique ?? Non, il n'a pas de sens.

Mettez toute votre logique sur un serveur Intel et laissez rip er! Si vous avez besoin d'échelle plus, clone la boîte. Toute la logique d'affaires est apatride (droit?), De sorte que vous pouvez monter en charge. Utilisez 3 machines de serveur « app », ou 4 ou 5 ou dont vous avez besoin mais beaucoup. Tout en cours d'exécution exactement le même code. Clones de l'autre. Peu importe combien de machines la logique métier que vous avez, ne distribuent pas physiquement la charge de travail. Pour une évolutivité maximale, s'efforcer de maintenir chaque transaction sur une seule boîte. C'est une recette pour une efficacité et une utilisation optimale des ressources.

Il est préférable d'utiliser les niveaux logiques dans l'architecture de votre application. Cela rend plus facile à développer et à entretenir. Mais ne croyez pas que la séparation logique doit impliquer, ou même recommander, une séparation physique. Ce ne est pas.