传递 IList与 IEnumerable比较 使用 protobuf-net
我在 protobuf-net 变更日志中注意到 IList<> 受支持,但我收到“无法创建接口实例”异常。 如果我更改为 IEnumerable<> 那么生活就美好了。 这听起来正确吗?
// Client call
public override IList<IApplicationWorkflow> Execute(IRoleManagement service)
{
IList<ApplicationWorkflowMessagePart> list = service.RetrieveWorkflows(roleNames);
IList<IApplicationWorkflow> workflows = new List<IApplicationWorkflow>(list.Count);
foreach (ApplicationWorkflowMessagePart a in list)
{
workflows.Add(new ApplicationWorkflowImpl(a));
}
return workflows;
}
// Service contract
[OperationContract, ProtoBehavior]
[ServiceKnownType(typeof (ServiceFault))]
[FaultContract(typeof (ServiceFault))]
IList<ApplicationWorkflowMessagePart> RetrieveWorkflows(string[] roleNames);
// Service implementation
public IList<ApplicationWorkflowMessagePart> RetrieveWorkflows(string[] roleNames)
{
IList<IApplicationWorkflow> workflows = manager.RetrieveApplicationWorkflows(roleNames);
IList<ApplicationWorkflowMessagePart> workflowParts = new List<ApplicationWorkflowMessagePart>();
if (workflows != null)
{
foreach (IApplicationWorkflow workflow in workflows)
{
workflowParts.Add(
ModelMediator.GetMessagePart<ApplicationWorkflowMessagePart, IApplicationWorkflow>(workflow));
}
}
return workflowParts;
}
谢谢, 迈克
另外,是否有文档网站提供此答案和其他答案? 我讨厌问新手问题。 :)
I noticed in the protobuf-net changelog that IList<> was supported but I'm getting the "Cannot create an instance of an interface" exception. If I change to IEnumerable<> then life is good. Does this sound correct?
// Client call
public override IList<IApplicationWorkflow> Execute(IRoleManagement service)
{
IList<ApplicationWorkflowMessagePart> list = service.RetrieveWorkflows(roleNames);
IList<IApplicationWorkflow> workflows = new List<IApplicationWorkflow>(list.Count);
foreach (ApplicationWorkflowMessagePart a in list)
{
workflows.Add(new ApplicationWorkflowImpl(a));
}
return workflows;
}
// Service contract
[OperationContract, ProtoBehavior]
[ServiceKnownType(typeof (ServiceFault))]
[FaultContract(typeof (ServiceFault))]
IList<ApplicationWorkflowMessagePart> RetrieveWorkflows(string[] roleNames);
// Service implementation
public IList<ApplicationWorkflowMessagePart> RetrieveWorkflows(string[] roleNames)
{
IList<IApplicationWorkflow> workflows = manager.RetrieveApplicationWorkflows(roleNames);
IList<ApplicationWorkflowMessagePart> workflowParts = new List<ApplicationWorkflowMessagePart>();
if (workflows != null)
{
foreach (IApplicationWorkflow workflow in workflows)
{
workflowParts.Add(
ModelMediator.GetMessagePart<ApplicationWorkflowMessagePart, IApplicationWorkflow>(workflow));
}
}
return workflowParts;
}
Thanks,
Mike
Also, is there document site that has this and other answers? I hate to be asking newb questions. :)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
目前,它支持将
IList
作为属性,只要它不必创建它 - 即允许类似的操作(为简洁起见,未显示属性):我必须检查一下,但出于类似的原因,我希望它可以与
Merge
一起使用,但不能与Deserialize
(这是 WCF 挂钩使用的)一起使用。 但是,我想不出它不能默认为List
的原因...目前还没有。最简单的选择可能是坚持使用
List
/T[]
- 但如果你愿意的话我可以看看......但我处于“目前正在处理一个(工作)项目,所以我今天无法打开引擎盖。关于“这个和其他答案”...有一个 Google 群组,但是不仅仅是 protobuf-net(protobuf-net 只是许多“协议缓冲区”实现之一)。
您还可以在项目网站上记录问题。 我确实想整理常见问题解答并将其添加到网站上的 wiki - 但时间并不总是我的朋友......
但是嘿! 我在这里...;-p
Currently it will support
IList<T>
as a property, as long as it doesn't have to create it - i.e. allowing things like (attributes not shown for brevity):I would have to check, but for similar reasons, I expect it would work with
Merge
, but notDeserialize
(which is what the WCF hooks use). However, I can't think of a reason it couldn't default toList<T>
... it just doesn't at the moment.The simplest option is probably to stick with
List<T>
/T[]
- but I can have a look if you want... but I'm in a "crunch" on a (work) project at the moment, so I can't lift the bonnet today.Re "this and other answers"... there is a google group, but that is not just protobuf-net (protobuf-net is simply one of many "protocol buffers" implementations).
You are also free to log an issue on the project site. I do mean to collate the FAQs and add them to the wiki on the site - but time is not always my friend...
But hey! I'm here... ;-p