问题描述
实现一个移动端访问数据库的webservice接口的流程，过程中要用到哪些东东，最好有实例。。。
解决方案
解决方案二：
用C#这个语言
解决方案三：
提供一个例子：Android客户端调用C#WebService。http://blog.csdn.net/chinacsharper/article/details/38386779
解决方案四：
没移动端部分，只有服务端部分
解决方案五：
这不就是webservice么..VS新建网站添加一个web服务写方法就搞定了啊..至于客户端(调用者)是c#还是java还是什么那是他的问题..好吧如果你不会webservice最起码的ashx你会吧....这也可以是接口输出json就行了.,什么?你连ashx也不会..那你最起码知道aspx吧...如果输出<html等标签那就是网页如果输出<xml或者{}那就是接口啊..如果你连aspx也不知道
解决方案六：
跨平台的话，用WebAPI好一点。可以使用Asp.netMVCWEBAPI模板简单例子:GettingStartedwithASP.NETWebAPI2
解决方案七：
从基本概念出发的话，你的客户端不是要去访问什么数据库，而是应该访问业务服务。至于业务服务是不是访问数据库、一个业务服务接口涉及多少数据库对象，那都是再次还不应该过多考虑的。在你的移动端去使用使用什么webservice的时候，你不应该考虑什么数据库。只有webservice的服务器端的程序设计才考虑数据库。可能你觉得“早晚不是都要考虑数据库吗？”，但是成熟的技术架构却要求你最少分为三层设计，你信吗？
解决方案八：
然后，如果更加接地气（接近你的实际开发层次）地考虑，是要搞懂你的移动端本身的及数据框架是什么。例如你在移动端主要使用jQueryAjax，那么你在服务器端就提供ashx之类的就是最快、最方便的；如果主要使用WebSocket，那么你使用Fleck等就是最方便、最稳定的（而且心跳机制也不用考虑了）；如果你支持一个tcp长连接，那么你的服务器端提供TcpListener则是最快、最稳定的。移动端的通讯要求使用比较轻量级的通讯，那些繁琐的“头信息、Schema信息”，或者什么冗余的短连接、重复连接方式，都应该尽可能去掉。因此webservice甚至wcf，是最坑爹的东西，应该尽量避免。
解决方案九：
是要搞懂你的移动端本身的及数据框架是什么--〉是要搞懂你的移动端本身所提供的数据通讯框架是什么
解决方案十：
引用7楼sp1234的回复:
然后，如果更加接地气（接近你的实际开发层次）地考虑，是要搞懂你的移动端本身的及数据框架是什么。例如你在移动端主要使用jQueryAjax，那么你在服务器端就提供ashx之类的就是最快、最方便的；如果主要使用WebSocket，那么你使用Fleck等就是最方便、最稳定的（而且心跳机制也不用考虑了）；如果你支持一个tcp长连接，那么你的服务器端提供TcpListener则是最快、最稳定的。移动端的通讯要求使用比较轻量级的通讯，那些繁琐的“头信息、Schema信息”，或者什么冗余的短连接、重复连接方式，都应该尽可能去掉。因此webservice甚至wcf，是最坑爹的东西，应该尽量避免。
在业务较复杂的情况下，使用ashx作为接口不是好的选择，定义过多的ashx后期很难维护。在没有使用webapi的情况下，还是要用ws或者wcf。