我有一个数据库，我认为它是我的应用程序，一个网站充当该应用程序的用户界面。现在是时候为我的应用程序添加更多用户界面（手机应用程序等）。
记住这一点，我想出了一个Web服务架构来向我的所有用户界面提供数据。我想用堆栈溢出的大脑来检查这个问题。顺便说一句 - 这是所有Azure托管的。
到目前为止，我认为这是合理的，尽管我对你的意见感兴趣。我想对下一点有点帮助：他们如何沟通。
我希望Core Web服务是一个只能在命名管道端点上访问的WCF服务 - 确保只有客户端Web服务可以与它们通信（我可以保证它们在同一台机器上）。 我希望客户端Web服务通过TCP或http绑定到他们的应用程序。该网站将在一台独立的机器上，但在同一网络上，因此是TCP的有力竞争者。应用程序当然会在客户端上，并且最好是我认为的http。
我担心我在这个设计中引入了太多步骤。使用注册作为示例，用户将使用进入Web服务器的网站页面进行注册，该Web服务器将调用网站Web服务上的注册方法，该网络服务将调用核心Web服务上的注册方法，该方法将调用注册方法。数据库中。
感谢您的想法！
（我发布了以下作为答案，但被告知。如果我们真的想要对此进行肛门，那么我想没有人应该发布任何答案，因为没有真正的答案 - 我是在征求意见，但无论如何...）
以防其他有类似设计问题的人有兴趣。我决定摆脱核心服务理念，只使用每个客户服务之间共享的类库。
优点：开发更容易，复杂程度更低（设置命名管道对我来说似乎不可能），并且可以减少一个进程（即使它在同一台机器上）。
缺点：现在每个服务都必须在Azure上，否则它无法访问Azure存储设施。我将使用队列来安排电子邮件。通过第一种方法，我可以在一个完全独立的平台上托管一项服务。
随意评论任何想法或观察。感谢您输入，Ramiramilu和Markus。
答案 0 :(得分：0)
您的方法似乎提供了良好的关注点分离。根据项目的大小，可能有点太多了。如果您正在寻找简化架构的方法，我的想法如下：
我建议分析Client WebServices的差异有多大，或者是否可以为所有客户端设置公共服务。即使您能够将大量共享代码移动到Core WebService，您也必须一遍又一遍地实现非常相似的接口。当然，这意味着不会有针对特定客户端需求的特定WebService。如果您在WCF上构建，您还可以提供具有不同绑定的服务，以便例如WebSite使用NetTcpBinding访问服务，而另一个客户端通过SOAP接口（WebHttpBinding或WSHttpBinding，根据您的需要）与同一服务进行通信。这样效率会更高，因为您不必为每个Client WebService实现常见的构建块，如身份验证和授权。
您也可以查看ASP.NET WebAPI并考虑构建一个可以从所有设备访问的REST API - 尽管它与TCP绑定一样高效。您还可以在WebSite项目中托管Web API，以便可以从其他客户端和AJAX请求中使用它。由于您的网站无论如何都可以通过互联网访问，从基础设施的角度来看，这也是一种很好的方法。
您可以将类库替换为Core WebService。客户端Web服务可以更容易地集成这一点，而不必处理额外的复杂性，例如，用于在Core WebService上进行身份验证 由于你想在同一台机器上托管Core WebService，我只会在有充分理由的情况下构建服务。我现在不能想出一个。
如果您的要求只是添加一些功能有限的客户端，我建议您在WebSite项目中添加Web API并从其他客户端访问它。有关详细信息，请参阅此link。