避免向使用 WCF 服务的客户端公开太多程序集
我在这里需要一些指导。我有一个 WCF 服务,它是一个更大的解决方案的一部分。目前,由于继承问题,最终消费者必须引用太多程序集。例如,这是我的基本项目设置:
MyProject.Domain
namespace MyProject.Domain
{
public interface IFooable{}
public class Foo : IFooable{}
}
MyProject.Contracts
namespace MyProject.Contracts
{
[DataContract]
public class FooData : IFooable{}
[ServiceContract]
public class IFooService
{
IEnumerable<FooData> GetFoos();
}
}
MyProject.Proxies
namespace MyProject.Proxies
{
public class WCFClient{}
}
问题就在这里:
class ConsumerCode
{
private WCFClient = new WCFClient();
void consumeService()
{
// Compiler error. No reference to MyProject.Domain.IFooable
var foos = WCFClient.GetFoos();
}
这意味着结束 -使用 FooData 对象的消费者还必须包含对 MyProject.Domain 的引用,这很糟糕,因为我不应该将业务逻辑层公开到最后 - WCF 的客户端 服务。
有办法解决这个问题吗?
I need a bit of guidance here. I have a WCF service that is part of a larger solution. Currently, too many assemblies must be referenced by an end-consumer due to inheritance issues. For example, here is my basic project setup:
MyProject.Domain
namespace MyProject.Domain
{
public interface IFooable{}
public class Foo : IFooable{}
}
MyProject.Contracts
namespace MyProject.Contracts
{
[DataContract]
public class FooData : IFooable{}
[ServiceContract]
public class IFooService
{
IEnumerable<FooData> GetFoos();
}
}
MyProject.Proxies
namespace MyProject.Proxies
{
public class WCFClient{}
}
The problem lies here:
class ConsumerCode
{
private WCFClient = new WCFClient();
void consumeService()
{
// Compiler error. No reference to MyProject.Domain.IFooable
var foos = WCFClient.GetFoos();
}
That means an end-consumer who uses the FooData object will have to also include a reference to MyProject.Domain, which stinks because I shouldn't have to expose the Business Logic Layer to the end-client of a WCF service.
Is there a way around this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
它非常简单 - 在合约中定义 IFooable,而不是在域中。
这里的逻辑是,暴露给客户端的任何东西(根据定义)都是合同或合同的一部分,而不是域实体。
Its pretty straightforward- define IFooable in Contracts, not in Domain.
The logic here is that anything that is exposed to the client is (by definition) a contract or part of a contract, not a domain entity.