3（物理）层架构是否效率低下？

Question

注意：当我提到tier时，我的意思是物理层。本网站上有关“层级”的许多问题都是指逻辑层，这不是我所要求的。

我正在使用标准的“3层”架构设计应用程序，包括演示，业务逻辑（BLL）和数据访问（DAL）层。该技术是WPF，C＃，LINQ和SQL Server 2008.我的问题与该应用程序的物理架构有关。

我可以将BLL / DAL放在一个标准的DLL中，该DLL在用户机器上加载并运行，形成一个2层架构 - 客户端机器和数据库服务器。但是将BLL / DAL转换为位于应用服务器上并从用户机器调用的WCF服务并不困难。这将给我一个3层架构 - 客户端机器，应用服务器和数据库服务器。

我的问题是 - 使用3层架构有什么好处？我经常被告知3层增加了可扩展性，但对我来说并不是很明显为什么会这样。当然，你要用同样的数据来打击性能，不得不通过线路进行两次跳 - 从数据库服务器到应用服务器，然后从应用服务器到客户端机器。

我很感激有经验的建筑师和开发人员的建议。

Answer 1

这取决于您的应用程序的使用和您的安全要求。如果您的应用程序是通过Internet使用的，并且您以任何方式存储任何可能敏感的内容，强烈建议为数据库添加物理删除。永远不要让任何人从外面进入任何可以直接访问您的数据库的机器。人们可以而且将会试图打破你的安全，没有比没有更好的事情更好的理由。

可扩展性也是一个因素，无论是在表示层之前（在Web服务器之前）还是在数据库中。将负载均衡器放置在表示层前面允许将传入请求路由到可以独立管理的计算机阵列。可以在需要时将机器添加到池中并移除以进行维护。在其他层之间放置负载平衡器可以产生相同的影响。我们的想法是提供灵活，动态的后端环境，可根据需求进行调整。

Answer 2

每当你发现自己问“X效率不高吗？”时你应该立即问自己三个前提问题：

1. “低效率”，您认为应该使用哪种资源有效而且可能不是？时间？空间？带宽？ 开发时间？

2. 你为什么关心？不，严肃地说：如果你要花一分钟时间回答这个问题，那就必须有理由。那是什么原因？

3. 与什么相比？

就您对可伸缩性的评论而言：有一段时间，我有一个不幸的责任维护一个系统，其架构师被告知最小化到数据库的往返将使应用程序可扩展。他采取了这种见解，并与它一起运行。您可以阅读有关此项目here的信息。在我看来，我应该提到的是，在该应用程序的整个十年以上的生命周期中，不会有超过四个用户同时登录。

Answer 3

低效率是旁观者的眼睛。

例如，在客户端上发生所有事情可能会增加客户端计算机的内存占用或CPU /网络要求。如果可以将此工作卸载到服务器/服务器场，则可以节省为了运行软件而必须对客户端PC进行硬件升级。如果需要更多资源或升级，可以在业务逻辑层中添加/完成它们，而不会影响客户端。

此外，当您需要在基于Web的系统或Outlook加载项中公开某些应用程序的功能时，在以后（从软件开发的角度）将业务逻辑放在其自己的层上可能会更高效，或者一个iPhone应用程序。只要业务逻辑略有变化，您就不希望更新所有这些系统。

安全性可能更好，因为您的用户不需要直接访问数据库服务器，它们由应用程序服务器隔离。

它还会迫使您以模块化的方式考虑您的应用程序，其中定义良好的接口可能会对您的应用程序设计产生架构优势。

Answer 4

可以。这取决于已实施的内容和方式。

创建3层物理架构的驱动力不一定与性能相关。

引用可伸缩性的原因是服务可能在服务器场上运行，但客户端不会意识到这一点。如果架构设计为支持它，则可以增加服务器场的大小以满足需求。

Answer 5

与您所描述的3t应用程序的主要优点是不可扩展性。可维护性可能。

为了使您的架构可扩展，您需要一种您未提及的技术。 - 你需要服务。我会建议WCF。

使您的BLL WCF服务（或多个服务）可以使您的应用程序更加高效和可扩展，允许您的BLL在不同/多台计算机上运行。