【发布时间】：2014-04-11 19:37:10
【问题描述】：
我查看了很多多层应用程序指南，但没有人谈到如何使用 wcf 来托管这些层。我计划制作一个测试项目，并且将有一个表示层/业务层/数据层以及业务对象由 EF 自动生成的类（数据库优先）。
问题是，在现实世界中，业务层和数据层是否都可以通过一个 wcf 主机也就是 2 台主机来访问？还是只有 1 个主机？
1 数据层和业务层之间 1 业务层和表示层之间
【问题讨论】：
【发布时间】：2014-04-11 19:37:10
【问题描述】：
为了清楚起见，
图层可能只是另一个项目，但在同一个盒子上。
层是代码在不同服务器上的物理分离。
您是使用层或层还是混合使用它们取决于需求。当我在一家也处理支付信息的医疗公司工作时，他们正在努力实现高水平的 PCI 合规性，因此我们有不同的层级。
我的 [括号] 是物理障碍，例如服务器和路由器。
[Front end -> MVC] -> [Firewall] -> [WCF -> Business layer servers] -> [Firewall] -> [WCF -> Database access] -> [Databases]
他们还有另一组层来专门处理从业务层分支出来的 PCI 数据。
这是否适合您的情况？这实际上取决于项目的要求。如果您的数据不需要高度安全，那么您可以坚持只使用图层。如果您打算拥有一些前端组件，例如移动平台和网站，那么您可以争取..
[Front end -> MVC] -> [WCF/WebAPI -> Business Layer -> Data access Layer] -> [Database]
这将允许您在共享公共业务层和数据的同时使用多个前端。同样，这完全取决于您的需求。我希望这会有所帮助。
编辑：安全性不是分层的唯一原因，可访问性和性能是另一个原因。如果您是一个重磅应用程序，拥有多个层级的服务器场，使用它们将带来一些优势。如果您的业务层位于 30 台服务器的服务器场中，您将拥有更宽的带宽和更多的处理能力。这些层可以分布在全国或世界各地，并设置规则，以便用户访问离他们最近的服务器。在为层开发时有很多考虑因素，从层开始可以让您在以后有需求时将它们物理地分成层。如果您将代码设计得很好，那么移动将向该层添加额外的服务层 WCF/WebAPI 以允许它访问分离的层，然后更新调用端以使用该服务而不是直接使用程序集。
【讨论】：
通常，您只托管业务逻辑。如果您同时托管业务层和数据访问层，则每个操作都有 3 个网络跃点：从演示到业务到数据访问到数据库。通过网络进行的每次传输都需要一些时间，因此您拥有的跃点越少，应用程序的性能就越好。
从架构的角度来看，最重要的是将应用程序的功能分成多个层，每个层都有特定的用途（关注点分离）。但是，基础架构视图是一个不同的视图，因此这并不意味着每一层都必须托管在服务器上。如果您有一个小型 Intranet 应用程序，只需将应用程序分层并在 UI 进程中运行所有这些就足够了。如果需求发生变化，您可以在以后轻松地以不同的方式布局图层。
【讨论】：