在ASP.NET解决方案中，如何调用物理分离的UI/BL代码？

在MSDN上描述了“分布式部署”（参见图2）。一切都很好

根据我的经验，我们总是按照他们所说的“非分布式部署”（图1）部署基于web的系统。我的理解是，在微软世界中，“应用服务器”作为一个独立的东西并不存在（就像在Java世界中一样），因为它实际上是“烘焙”到OS/Windows的

所以我的问题是，如果要将UI和业务逻辑（BL）分发到不同的服务器/层，它们将如何通信

---

我知道一个答案是使用“服务层”——有哪些替代方案？你会怎么做呢？从代码的角度看它是什么样子？

首先。不要这样做。别这样。你会陷入痛苦的世界。逻辑层和物理层是不同的。应用程序层的逻辑分离是一个好主意。应用程序层的物理分离往往会导致灾难。如果有一个很好的部署原因（另一个盒子上的共享支付处理器），当然，请继续。您可以使用我们都知道和喜欢的标准机制—WCF、MSMQ、HTTP。。。选择你的毒药。但不要为了实现MSDN白皮书中的某种神话般的理想而承担开销和复杂性。

首先。不要这样做。别这样。你会陷入痛苦的世界。逻辑层和物理层是不同的。应用程序层的逻辑分离是一个好主意。应用程序层的物理分离往往会导致灾难。如果有一个很好的部署原因（另一个盒子上的共享支付处理器），当然，请继续。您可以使用我们都知道和喜欢的标准机制—WCF、MSMQ、HTTP。。。选择你的毒药。但是，为了在MSDN白皮书中实现一些神话般的理想，不要承担开销和复杂性。

< P>应用服务器是为帮助一种稀缺资源而计算出来的：在中间层计算能力。这个想法来自大型机领域，最初，在大型机领域，CPU稀缺且昂贵，因此大量的时间、精力和金钱被花费在将大型机CPU分配给不同的用户、限制工作负载、保持数据库负载、“钝化”事务，直到数小时后负载减少，等等。在那些日子里，人们花了数百万美元在跟踪大型机交易的软件上，以便能够执行“按存储容量使用计费”（chargeback）——使用昂贵的ive大型机的内部成本核算。是的，人们花了很多钱，这样他们就可以向内部部门支付使用大型机的费用

问题是，英特尔（以及后来的AMD）、思科（Cisco）等公司、EMC、微软和Linux都将整个想法付诸实践。计算机变得便宜了。真便宜。真的，真的，真的没有必要定量分配中端计算资源。现在双cpu服务器的用途是什么？你可以为一个IT人员的年薪部署多少？这是对旧的大型机计算经济学的颠覆，在大型机计算中，计算机是昂贵、稀缺的资源，而人们相对（！！）便宜。现在人是昂贵的部分，而计算机是便宜的

应用程序服务器，以及它们为限制对计算的访问、将计算打包、限制计算、甚至为按存储容量使用计费而“监控”交易所做的一切努力。。。。当你有廉价AMD服务器的机架时，这些东西是不必要的

应用服务器做的另一件事是保护数据库不受工作负载的影响。基本上，从db服务器卸载工作。曾经，开发人员将业务逻辑放在存储过程中，然后，砰的一声，出现了你的应用程序。但这种方法存在可伸缩性问题。不过，现在，存储过程又快又高效。数据库服务器可以廉价地扩展。有可能的是，您没有一个在英特尔硬件上无法承载的世界上排名前100的工作负载卷，其中包括存储过程逻辑

然而，存储过程方法的一个主要问题是，用主流语言（Java、C#、VB等）编写并管理存储过程仍然有点困难。是的，我知道数据库管理的SQL CLR和Java虚拟机。但这些都不是主流方法。另外，DB管理员不喜欢代码骑师把他的利用率图弄乱。出于这些原因，仍然希望用专用于此目的的单独语言编写业务逻辑。人们仍然希望在专用计算资源上运行和管理该逻辑。但是传统的“应用服务器”？？不，没有道理

把你所有的逻辑都放在一个英特尔服务器上，让er撕裂！如果需要更大的比例，请克隆长方体。所有的业务逻辑都是无状态的（对吗？），因此您可以扩展。使用3台“应用程序”服务器，或4台或5台，或您需要的任何数量。都运行完全相同的代码。彼此的克隆。无论您有多少台业务逻辑机，都不要实际分配工作负载。为了获得最大的可扩展性，请努力将每个事务保存在单个框中。这是提高效率和优化利用资源的秘诀

---

在应用程序体系结构中使用逻辑层是最佳实践。这使得它更易于开发和维护。但不要认为逻辑上的分离必然意味着，甚至建议物理上的分离。事实并非如此

应用服务器被认为是一种帮助稀缺资源的工具：计算中间层的力量。这个想法来自大型机领域，最初，在大型机领域，CPU稀缺且昂贵，因此大量的时间、精力和金钱被花费在将大型机CPU分配给不同的用户、限制工作负载、保持数据库负载、“钝化”事务，直到数小时后负载减少，等等。在那些日子里，人们花了数百万美元在那些