我们正在开始开发一个Web应用程序，该应用程序稍后也将移植到移动设备上。所以我想在WCF层中封装数据访问和业务逻辑。这样可以让以后更容易同步和管理它。
数据访问层将由ORM（Codesmith - PLINQO）上方的存储库层组成。 该应用程序是多租户（SaaS）并使用共享数据库方法。
WCF和Web App将驻留在同一服务器上，WCF Binding将是NamedPipes。
上述方法是否正确或使用WCF层可能会遇到一些影响？任何有关更好地构建应用程序的建议或可读材料也受到欢迎。
答案 0 :(得分：2)
这取决于您的其他要求。命名管道通信始终受到性能影响。您可以直接进行多次测试以直接调用操作，并通过命名管道调用操作来获取一些数字进行比较。除了另一个进程 - null channel或local channel之外，还有其他命名管道来托管服务，但即使这些解决方案仍然比直接调用更慢。
您正在为未来规划您的架构，因此您现在应该定义未来的意义。移动设备如何使用您的服务？它会是SOAP还是REST？这是两种不同的方法，您可以发现您为Web应用程序（SOAP）准备的服务对于移动设备（您可以使用REST，因为它受到更好的支持和更受欢迎）并不是非常有用。
如果你不知道未来是什么意思做任何准备是没有意义的，因为你很可能会为不会发生的事情做准备=你当前的努力将被浪费，你无论如何都要改变你的申请
为您的应用程序（=内部服务）和移动设备（=外部服务）使用相同的服务可能有不同的安全要求。例如，您的Web应用程序已经可以处理授权，但对于移动设备，必须在服务上执行授权。授权是服务的全球性，因此对于您的Web应用程序，您将进行两次授权。
在我看来，你应该从业务逻辑开始作为一个库，它将由你的web应用程序直接使用。一旦您需要为移动设备添加服务，就可以围绕业务逻辑创建服务包装器。如果要在不同服务器上划分前端和后端，或者如果要分别扩展业务逻辑和前端，但是当它们在同一服务器上运行时，只会引入性能下降，那么为Web应用程序添加WCF层是有意义的。可能不会让您的移动设备开发更容易。即使在您将单独部署业务逻辑的情况下，您也应该仔细考虑是否要将业务服务直接暴露给移动设备。公开调用内部业务服务的另一层公共服务并不罕见 - 这通常用于具有严格安全性的项目中，其中业务服务必须位于不同的网络边界。