Argotic Syndicate 框架 v. System.ServiceModel.Synmination
我正在研究 Argotic Syndicate Framework，到目前为止给我留下了深刻的印象。 然而，当前的许多实现（至少对于 RSS 和 Atom 来说）看起来相当相似 到 System.ServiceModel.Synmination。 有人对其中之一有什么看法吗？
I'm investigating the Argotic Syndication Framework, and I'm pretty impressed so far. However, a lot of the current implementation--at least for RSS and Atom--seem pretty comparable to System.ServiceModel.Syndication. Does anyone have any opinions as to one over the other?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
以下是我在遵循这两条路径后的观点：
System.ServiceModel.Symination
Argotic
Here's my perspective after having followed both paths:
System.ServiceModel.Sydication
Argotic
如果您只需要 RSS 和 Atom，我会选择 System.ServiceModel.Syndicate。 抛开其他因素不说，与开源替代方案相比，使用 .NET 框架有一个显着的好处：熟悉。 如果您选择使用 Argotic 框架，那么这是您的开发团队的新成员必须学习的另一个第三方组件（或者您需要在潜在候选人中寻找的其他技能）。如果您选择使用.NET Framework 解决方案，您拥有数百万潜在的程序员，他们可能已经知道它。 即使他们不知道 System.ServiceModel.Syndicate，它也遵循与 .NET 框架的其余部分相同的一致标准，这仍然为大多数 .NET 开发人员提供了熟悉的元素。
虽然 OSS 通常可以为小问题领域提供一些有趣的选项，但当涉及常见问题领域时，不要低估熟悉性和普遍性的价值。 多样化的框架通常意味着开发团队的新成员需要更陡峭的学习曲线、框架之间的集成成本更高、版本控制和安全问题等。
If all you need is RSS and Atom, I would go with System.ServiceModel.Syndication. Barring everything else, there is one significant benefit to using the .NET framework over open source alternatives: Familiarity. If you choose to use the Argotic framework, thats another third-party component that new additions to your development team are going to have to learn (or another skill you will need to look for in your potential candidates.) If you choose to use the .NET Framework solution, you have the potential pool of millions of programmers at your disposal who will likely already know it. Even if they do not know System.ServiceModel.Syndication, it follows the same consistent standards as the rest of the .NET framework, which still provides an element of familiarity to most .NET developers.
While OSS can often offer some intriguing options for nitch problem areas, when it comes to common problem areas, don't underestimate the value of familiarity and ubiquity. A diverse palette of frameworks generally means a much steeper learning curve for new additions to a development team, greater cost of integration between frameworks, versioning and security issues, etc. etc.