wcf接口是返回string还是应该返回list

[tzdm889]

我想用wcf做一个微信接口，比如有一个方法获取部门列表，
1.一般来说是返回string（xml序列化）比较好还是返回list<T>比较好
2.如果客户端非.net平台，是不是只能返回string（xml序列化）了

[全栈极简]

返回json格式的字符串。

[tzdm889]

引用 1 楼 guwei4037 的回复:

返回json格式的字符串。

这么说来针对非.net平台的接口只能返回string类型了（xml或者json）？

[全栈极简]

也可以返回数组，但解析起来比较麻烦。为了通用，尽量采用平台无关的数据结构（字符串）。

[tzdm889]

引用 3 楼 guwei4037 的回复:

也可以返回数组，但解析起来比较麻烦。为了通用，尽量采用平台无关的数据结构（字符串）。

明白了

[by_封爱]

只要是接口 一般一律返回json形式的字符串.. 什么wcf webservice 都扯淡.. 就简单的http就好高效快速...

[以专业开发人员为伍]

这个设计的出发点不是标题党式的，首先要说明你的客户端基础假设是什么。 比如说客户端就是传统、通用的 http get/post 模式，那么当然你当然是返回 json 字符串来表示返回对象（或者对象数组）就好了。假设你的 web 客户端本身就是基于 wcf 的，那么你返回 T[ ] 这样的数组形式则是 wcf 最规范的方式。 因为 wcf 毕竟有一大堆复杂的封装、解析程序，它明明可以以强类型的基本类型对象的数组为规范，为什么要纠结 string 呢？纠结 string 那么何必又要使用 wcf 呢？ 其实你的问题应该问的是“使用 wcf 还是不使用 wcf ”的问题。而假设你使用 wcf 那么就不应该纠结什么 string 了。

[以专业开发人员为伍]

客户端开发者比如说很习惯 ajax.post、WebClient/HttpClient 等等轻量级调用方式，那么当然你就用轻量级的服务形式。而假设前端有很复杂的 wcf/webservice 客户端代码机制已经封装好了，那么当然就服务器端设计为 wcf 的也没有什么逻辑上的问题（只不过是性能问题而已）。这个设计的出发点在于前端的需求。 wcf 本来的初衷就是封装一下参数，它有着一大堆参数序列化、参数格式发现等等的复杂规定。它假设你从来不写 JsonConvert.SerializeObject(obj) 这样的一行代码。而你先入为主地纠结 WCF，又要拼命用起来 WCF 又要把它的服务参数规范彻底抹杀掉，这又何必要用 wcf 呢？ 如果是这样，那么还是从此用不使用 wcf 为好！！

[正怒月神]

返回 json格式的字符串

[以专业开发人员为伍]

许多 c# 初学者是因为没有 http 通讯基础（没有其它编程训练），直接照搬 c# 教程，对 wcf 产生了先入为主的印象。 实际上使用还是不使用 wcf，我也不想说一个很绝对的话。但是我想说的是，如果你用wcf 就应该用好它，而不是把它的核心价值给抹杀掉。这就好像你要住一个六星级别墅，但是把别墅的四面墙壁都拆掉了、装上茅草以便乘凉，那么你何不直接住在一个四面透风的院子中央呢？ 用 wcf 就是要把它的参数封装机制用起来，这是它面对轻量级的 web 通讯协议的竞争而最后剩下的一点点价值。否则就永远不要用 wcf。