WCF - 主“路由器”
我的任务是为移动设备（如iphone/android/BB/等）创建一个应用程序，该应用程序的目的是告诉用户网站上有新内容，然后显示一个列表（在应用程序内） ）显示最新更新。
公司坚持要求我使用ASP.NET/C#/Visual Studio并使用SOAP协议。
我开始使用 C#，然后使用所谓的 WCF。
我已经有一些东西在工作了。 （就像从 Android 应用程序“使用”WCF 并获取发回的数据一样）。
我的问题是移动应用程序开发的最佳“架构”是什么。我正在考虑只有 1 个 WCF，然后调用一个通用函数，如 Do() （或其他名称:)），然后添加一个肥皂头，您可以在其中定义您想要服务执行的操作。就像从数据库中获取记录，或者 ping ，呃其他什么，无论公司将来可能需要什么:)
这将如何工作：
客户端（移动应用程序）将调用 WCF，并且在肥皂头中是比如说，它想要使用设备 ID 注册手机。 WCF 将接收 Soap 请求，提取标头并使用某种开关来决定它需要做什么。例如，一旦它知道要做的事情，WCF 将访问一些本地类来插入/检索数据库数据或执行其他操作，完成后它将简单地返回所需的内容。 （比如 OK 标志或数据或其他东西..:)）。
这是一个正确的方法吗？因为我如何看待这个问题，它使得后端的更改变得非常容易，而无需更新应用程序。
很抱歉，如果这是一个迟钝的问题，但我是 WCF 和移动应用程序开发的新手，并且我正在努力在实习结束时提供出色的产品。我只是想知道你们建议我使用哪种“架构”来完成此类任务。
编辑
我已经告诉他们 SOAP 对于移动开发来说太重了并向他们展示了一些图表。但他们坚持使用他们已经知道的技术。
经过一些研究后，我确实认为基于合同的方法是更好的方法。但你能回答几个有关它的问题吗？
- 我可以拥有一个可以“使用”的 WCF 文件来保存所有不同的操作吗？
- 我可以在 WCF 开始时对客户端进行身份验证（需要使用 Soap 标头），然后调用所需的操作吗？
My assignment is to create an App for a Mobile Device (Like iphone/android/BB/etc..), the purpose of this app is to tell the users there is something new on the website and then show an list (inside the App) showing the latest updates.
The Company insisted I use ASP.NET/C#/Visual Studio and use the SOAP protocol.
I've started working with C# and then using the so called WCF.
I've already got some stuff working. (Like "consuming" the WCF from an Android App and getting data sent back).
My Question is what will be the best "Architecture" to work with for the Mobile App Development. I was thinking about have only 1 WCF and then call a general function like Do() (Or some other name :)) and then adding a soap header where u can define what u want the service todo. Like getting a record from the database, or ping , er something else, whatever the company may need in the future :)
How this would work:
The Client (Mobile App) would make a call to the WCF, and in the soap header is states, lets say, it wants to register the Phone with the Device ID. The WCF will receive the Soap Requests, extract the header and use some sort of switch to decide what it needs todo. Once it knows that to do the WCF will then, for example, access some local Classes to insert/retrieve Database data or do something else and when its done it will simply return what is needed. (Like an OK sign or data or something else.. :)).
Is this a right approach, cause how I am looking at this, it makes it very easy for changes on the back end without updating the App.
Sorry if this a retarded question, but I am new to WCF and Mobile App Development, and i'am trying to deliver a great product at the end of my internship. I was just wondering what sort of "Architecture" you guys suggest I would use for this sort of assignment.
EDIT
I already told them SOAP is too heavy for mobile development and shown them some graphs. But they insisted to use techniques they already know.
After doing some research I indeed think the contract based approach is the better way to go. But can you maybe answer a few questions regarding it?
-Can I have like one WCF file that gets "consumed" which holds all the different operations?
-Can I authenticate the client (With using Soap headers Required) at the beginning of the WCF and after that call the desired operation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
人们普遍认为 SOAP 对于移动开发来说有点太重了。由于用户可能会产生数据费用并且通常具有较低的带宽，因此最好采用 REST/JSON 方法。您仍然可以使用 WCF 在服务器上执行此操作。
您可以使用通用操作 (MessageAction="*")，但随后您需要自己处理消息的序列化/反序列化。但是，除非您有迫切的理由这样做，否则我建议正确构建的操作是更好的方法。它们更易于维护。只要消息契约不改变，您仍然可以在服务器上进行实现更改，而不影响客户端。现实情况是，如果您想更改消息或操作合同，无论如何您都必须对客户端进行更改。考虑到这一点，基于“合同”的方法只有优点，没有真正的缺点。
SOAP is generally regarded as a little too heavy for mobile development. Since users may incur data charges and generally have lower bandwidth, it would be preferable to take a REST/JSON approach. You can still use WCF to do this at the server.
You can use a generic operation (MessageAction="*") but you will then need to handle the serialisation/deserialistion of messages yourself. However, unless you have a pressing reason to do this I would suggest properly structured operations are the better way to go. They are much more maintainable. You can still make implementation changes at the server without affecting the client, as long as the message contract does not alter. The reality is that if you want to change the message or operation contracts you will have to make changes to the clients anyway. After considering this, the 'contract' based approach only has upsides and no real downsides.