将 wcf 服务契约与接口定义分开有什么价值吗？
我有一个接口 ICustomerService:
public interface ICustomerService
{
CustomerList FindAll();
}
和一个实现该接口的具体类。现在我需要使用 wcf/rest 在网络上公开该方法，并且我必须将接口定义更改为：
[ServiceContract]
public interface ICustomerService
{
[OperationContract]
[WebInvoke(
Method = "GET",
UriTemplate = "Customers")]
CustomerList FindAll();
}
我的问题是，如果有客户端想要将这些属性附加到您的接口，是否有任何缺点使用 dll 引用的实现而不是使用其余 api？我知道使用 REST 的缺点，例如如果参数位于 uri 中，则必须将参数设置为字符串类型。
I have an interface ICustomerService:
public interface ICustomerService
{
CustomerList FindAll();
}
and a concrete class implementing that interface. Now I need to expose the method over the web using wcf/rest and I've had to change the interface definition to this:
[ServiceContract]
public interface ICustomerService
{
[OperationContract]
[WebInvoke(
Method = "GET",
UriTemplate = "Customers")]
CustomerList FindAll();
}
My question is if there is any downside to having these attributes attached to your interface if there are clients that want to use the implementation using dll reference instead of using the rest api? I am aware of the shortcomings in using REST like having to have your parameters as type string if its in the uri.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
除了代码可读性之外（如果您的客户必须查看您的接口源代码），属性应该没有任何缺点。
任何感兴趣的人（例如 WCF 框架）都可以读取这些属性，否则将被忽略。实际上，它们在任何实现类中都是不可见的（请参阅这个问题< /a>）。
然而，在架构级别，请考虑使用 2 个接口，一个用于 dll 引用客户端，一个用于 REST 客户端。它们一开始可能很相似，甚至可能共享相同的基本接口和实现，但是如果业务案例需要，您可以使它们相互转移。
此外，这使您可以在 WCF Web 应用程序项目中保留 WCF 属性填充接口，并在核心类库项目中保留干净的接口和实现。
There should be no downsides of the attributes except maybe in code readability (if your clients have to look at your interface source).
The attributes can be read by anyone interested (like the WCF framework) or will be ignored. Actually they won't be visible from any implementing class (see this question).
At the architecture level however, consider using 2 interfaces, one for the dll-referencing clients and one for the REST clients. They might be similar the begin with, they might even share the same base interface and implementation, but you have the ability to make them divert from each other if the business case requires it.
Also, this gives you the possibility to keep the WCF attribute filled interfaces in the WCF web application project, and the clean interfaces and implementations in a core class library project.