.net 使用WCF数据访问&；业务逻辑层

我们正在开始开发一个web应用程序，该应用程序稍后也将被移植到移动设备上。所以我想将数据访问和业务逻辑封装在WCF层中。这将使以后更容易进行同步和管理

数据访问层将由ORM（Codesmith-PLINQO）之上的存储库层组成。 该应用程序是多租户（SaaS），并使用共享数据库方法

WCF和Web应用将驻留在同一台服务器上，WCF绑定将命名为dpipes

---

上述方法正确吗？或者使用WCF层可能会影响性能？我们也欢迎为更好地构建应用程序而提供的任何建议或可读材料

这取决于您的其他需求。命名管道通信总是影响性能。您可以进行一些测试，多次直接调用operation，并通过命名管道调用operation，以获得一些要比较的数字。有替代命名管道的方法来承载进程中的服务，而不是另一个进程——或者，即使这些解决方案也比直接调用慢

您正在为未来规划架构，因此现在还应该定义未来的含义。移动设备将如何使用您的服务？是肥皂还是休息？这是两种不同的方法，您会发现为web应用程序（SOAP）准备的服务对于移动设备（您可以在移动设备上使用REST，因为它得到了更好的支持和更受欢迎）不是很有用

如果你不知道未来意味着什么，那么做任何准备都是没有意义的，因为你很可能会为一些不会发生的事情做准备=你当前的努力将被浪费，你以后无论如何都必须更改你的应用程序

对应用程序（=内部服务）和移动设备（=外部服务）使用相同的服务可能会有不同的安全要求。例如，您的web应用程序已经可以处理授权，但对于移动设备，必须对服务执行授权。授权对于服务来说是全局的，因此对于您的web应用程序，您将执行两次授权

---

在我看来，您应该从业务逻辑作为一个库开始，它将被您的web应用程序直接使用。一旦您需要为移动设备添加服务，只需围绕您的业务逻辑创建服务包装。如果希望在不同的服务器上划分前端和后端，或者希望分别扩展业务逻辑和前端，那么为web应用程序添加WCF层是有意义的，但当它们在同一台服务器上运行时，这只会导致性能下降，并且可能不会使移动设备的开发更容易。即使在需要单独部署业务逻辑的场景中，若要将业务服务直接公开给移动设备，也应该仔细考虑。公开另一层称为内部业务服务的公共服务并不少见，这通常用于具有严格安全性的项目中，其中业务服务必须位于不同的网络外围

您的移动应用程序是否有不同的绑定进行连接？我会使用http。。。仅一个commentWCF就可以支持多个绑定，因此对于移动应用http和名为pipe/tcp ip的网站来说都是如此