.NET web应用中的3层体系结构

Question

如今，大多数系统都被设计成网络应用程序。在.NET世界中，著名的三层体系结构通常是这样翻译的。

• 前端(Web应用程序)
• 中间层(使用ORM访问和处理数据的自定义DLL)
• 后端( Server、Oracle、MySQL)

对我来说，中间层实际上不是中间层，因为无论中间层有多孤立，它都在web服务器的上下文中执行(因为它驻留在DLL中)，并且本质上是web应用程序的一部分。

我的问题：

1. 说三层拱是简单的二层拱是正确的吗？
2. 设计这些需要大量数据处理的应用程序，没有物理上独立的中间层，这是正确的吗？
3. 除了在WCF或Windows服务中托管它之外，还有哪些选项可供中间层使用？

Answer 1

对我来说，中间层实际上不是中间层，因为不管设计有多孤立，DLL有多无状态，它们只在web服务器的上下文中执行，本质上是web应用程序的一部分。

不，当涉及到大型应用程序时，中间层可能完全位于另一个服务器(S)中。例如，您可能将web前端托管在一台服务器中，并与承载域模型逻辑的另一台服务器进行通信。另外，取决于您的系统的需求，它可以是多个服务器。

我的观察和理解是否正确?3层拱门不是真正的3层拱，而是简单的2层拱？

请参阅前面的评论。

在没有技术中间层的情况下，即使是需要大量处理的应用程序，采用这种方式设计应用程序是否正确？

当需要大量处理时，使用web服务器进行处理并不是最理想的，因为这会影响用户体验，他们可能会注意到网站是“慢”的。您可以将繁重的/耗时的处理委托给另一台服务器，并适当地将结果显示给用户(推送而不是等待屏幕)。

对于web应用程序来说，当前是中间层的唯一选择是windows服务，而不是其他？

1. 它可以是具有公开web服务的应用服务器。
2. 订阅队列的可伸缩角色(类似于microsoft提供的角色)

Answer 2

无论您将“中间层”代码放置在前端站点加载的DLL中，还是将其放置到单独的web服务应用程序中，都只是一个细节。此位置决策不会以有意义的方式更改代码体系结构。这更像是一个部署决定。

1. 不，这些层不是由物理部署决策定义的，而是由代码体系结构和数据流定义的。
2. 我将把你的问题中的“正确”改为“明智的”，并回答这个问题。什么是明智的，是什么使你最有效率。需要时使用“中间层”(这不是严格要求的)。例如，它可以帮助从UI代码中解开逻辑，并允许使用相同的业务逻辑拥有多个前端。
3. 同样，您可以将“中间层”代码放置在任何您喜欢的地方。它可以位于DLL中、WCF web服务中或Windows服务中。这纯粹是一个部署决定。相关的关注点是简单性、故障隔离、安全性和性能。

“后端”这个词对不同的人来说意味着很多事情。复杂的现实世界系统通常由许多组件组成.通常没有一个组件可以识别为“最后一层”。“后端”是一个相对的术语。

Answer 3

在“逻辑体系结构”和“物理体系结构”之间有一个区别，您可以拥有相同的代码库，但是可以在Web层和中间层上部署它，或者严格地在Web层上部署它。

你的决定是基于无数的因素。如果您的Web层只是在中间层调用多少镜像服务的一个通道，那么在我看来，中间层是没有意义的。这种不必要的物理架构增加了硬件成本，因为大多数企业级应用程序都需要所有层的冗余服务器。还会使部署和维护复杂化。记住最终目标，您可以构建最好的应用程序，但是如果复杂的部署和维护占用了您的开发时间，那么它值得吗？该中间层服务器将更好地用作Web层上的另一个负载平衡服务器。另外，网络延迟开销在层间是最慢和最不可靠的，而如果您在不跨越进程边界或通过网络进行远程处理的情况下调用内存JARS或DLLS，那么显然处理和响应时间对于较高流量场景是最快的。

然而，它并不是一刀切的，适用于所有的解决方案。对于应用程序中的某些功能，您可能需要消息队列或后端服务或Chron服务或Windows服务。例如用于断开连接的工作流，或长时间运行的密集处理。它确实可以被认为是其他业务服务的Web层之外的中间层或“另一层”层。

最好的经验法则是永远不要过度复杂什么是企业所必需的。简单的工作，复杂的失败。