我应该如何构建我的应用程序以支持移动应用程序

时间:2012-05-10 21:32:37

标签: c# wcf mobile architecture asp.net-web-api

我正在寻找有关我的系统架构的帮助。让我概述一下:

我有一个sql server和oracle数据库,可通过一组wcf服务访问。

这些wcf服务端点被许多Web应用程序使用。

所有应用程序都是用.net c#4.0编写的。

现在需要一个移动应用程序(iPhone应用程序,Android应用程序)来访问数据库提供的数据。

我的第一个问题是,向移动应用提供数据的最佳媒介是什么?我相信的选项包括我所拥有的wcf服务或包含项目(调用现有的wcf服务),这些项目公开了移动应用程序可以访问的WebApi或MVC控制器。关于移动应用程序消费的最佳方法的建议。请注意移动应用程序需要一个小的有效负载,并且还需要采取安全措施来防止未经授权的移动应用程序访问服务/包装器项目。

我的下一个问题是关于WCF服务的版本控制。我希望能够无缝地更新wcf服务,而不会影响潜在的包装器项目,反之亦然。由于第三方移动应用程序将处于不同的发布周期,因此需要支持多个版本。我希望这可能涉及部署应用程序的多个版本,但想知道如何正常处理这种做法?

所有应用程序都部署在IIS 7.0中的Windows服务器上。

4 个答案:

答案 0 :(得分:2)

嗯......我对听到其他答案非常感兴趣,但这是我对你的问题的看法。

首先,我认为您应该将业务逻辑与WCF服务分离,如果您还没有。这使您可以与WCF服务并排设置ASP.NET Web Api服务。它不是将一些MVC或Web Api调用到您的WCF中,而是可以并排作为替代方案。

您也可以在WCF服务中创建Json端点,即使我更喜欢同时拥有WCF和Web Api,因为最新的更具互操作性。如果您将所有逻辑与服务分离,那么它们应该变得相当简单,即分享所有业务逻辑。

对于您的移动iphone和Android应用程序,使用Web Api服务可能更容易。我在维护Api服务的几个版本方面不是很有经验,但是如果您将移动应用程序连接到Web Api服务,则可以通过为每个api版本创建多个文件夹来进行版本控制。这将导致业务逻辑重复......

正如我所说,我对其他意见非常感兴趣。

答案 1 :(得分:1)

我肯定会将JSON视为我的数据格式,正如Dante所说。也按照建议拆分为n层。

就Auth而言......

你有多少第三方应用程序?这听起来并不像你有很多,但如果你这样做(而且他们是真正的第三方,即你不受你的控制),那么你可能想看一下OAUTH解决方案。

如果你只有少数人并且你处于控制之中,那么IMO就是过度杀戮,相反,我只有一个每个应用都知道的简单密钥。每次调用都会传递密钥,服务会对此进行检查。显然,所有传输都应该通过SSL进行,因此没有人可以窃听密钥或数据的内容。

在检查密钥方面,您需要使用方面或自定义属性来避免在每个函数上编写样板。

答案 2 :(得分:1)

如果您需要移动支持,最好避免使用WCF并使用Web API。原因是,虽然所有原生移动平台都可以使用XML,但在WCF中您可以使用基本HTTP绑定来模拟旧式Web服务,Web API通过HTTP提供精简和平均的通信,可以由这些平台的浏览器也是如此,而不仅仅是本机代码。

如果它具有移动性和互操作性,我会毫不犹豫地使用Web API。

我只会在certain conditions中使用WCF。

答案 3 :(得分:1)

如有疑问,请插入抽象。 我想你已经构建的服务已经作为域服务。这些服务通过模型(DTO)和更新(API)为具有不同需求的多个客户提供服务。为了实现您可以轻松版本并且能够灵活地减少线路上的内容,请为要支持的屏幕引入一个层。

我建议建立一个“移动服务”,它只能依赖域服务,并有办法将DTO转换为移动耗材块。该层可以位于ASP.NET WebAPI中,也可以位于vert.x或node.js之外,以便您可以根据需要启动功能。最后,您想要的是域和消费者之间的服务合同,并在它们之间引入一个层,从长远来看,可以让您在没有巨额成本的情况下替换任何一端。它允许您根据需要对API进行版本控制,而无需重新触摸整个堆栈。

当然,您可能希望考虑一种方法,让客户端设备提前告诉您,他们需要从您的服务中获得哪些功能,以便您可以确定要达到的逻辑端点。这将允许您打开客户端和域之间的版本协商方式。

我建议查看LinkedIn基础架构,了解他们如何构建移动应用程序(是的,他们不使用ASP.NET,但架构模式仍然健全)。

我的2c。