当使用 5 层架构（前端 => 接口层 => 业务层 => 数据库层 => 数据库）使用 WCF 服务作为接口层时，让客户端应用程序调用它的方法，我是否也应该使用业务和数据库层的 WCF 服务？我问，因为 3 个服务之间将进行的所有序列化/反序列化可能会消耗服务器的大量 CPU，并对整个应用程序的性能产生影响，还是我错了？
在一台机器上运行所有3个组件层的情况下，将业务层和数据库层构建为简单的类库，而只保留接口层为WCF更好吗？
提示
【问题讨论】：
标签： wcf serialization n-tier-architecture
WCF 对于物理机之间的通信很有用。尽管您可以使用 WCF 进行进程内通信，但有更简单、更有效的方法来完成同样的事情。如果您考虑在某个时候将不同的层放在不同的机器上，您只会使用 WCF 进程内。至于将 WCF 用于数据库层，您不会：您将使用 System.Data.xxx 命名空间中的类（即 System.Data.SqlClient，如果您使用的是 SQL 服务器数据库；或者可能是实体框架） .
当人们谈论 3 层架构时，他们将两个概念混为一谈：物理层：客户端机器、中间件机器和数据库机器；软件架构中的逻辑层：客户端 UI 代码、业务逻辑代码和数据访问代码。当来自位于同一物理机器上的两个不同逻辑层的代码需要进行通信时，最简单的模型是一个类调用另一个类，解耦量取决于您的要求。您想使用满足您要求的最简单模型。 Rockford Lhotka 在他的书Expert C# 2008 Business Objects
的第一章中对此进行了很好的描述【讨论】：
分层架构是一种前 SOA 方法，尽管我们今天仍在我们的软件中构建逻辑层。但是物理层，如果多于一层（除了 UI 和数据库），会给你带来痛苦和心痛。有时您最终会拥有两个，但我个人建议不要这样做。
Trend 正在使用 Service Bus 或类似方法使用并行/解耦处理，不建议构建串行服务。
您已经指出了序列化开销。但这只是开始，您会遇到方法执行延迟、更多故障点、由于层与进程对话导致性能下降、维护开销……
所以不要因为只有一个中间件物理层而感到抱歉，这不是资产而是负债。
【讨论】：