在我的公司,我们的服务实现基本上只是将回调传递给业务层,该业务层进行实际处理。因此,举例来说,如果我们有一个服务合同,看起来像这样:动态生成服务实现
public interface IService
{
void ServiceMethod1(string a, object b);
int ServiceMethod2(int a, int b);
}
我们的服务可能看起来就像这样:
public class Service : IService
{
private ServiceBL _serviceBL;
public Service()
{
_serviceBL = new ServiceBL();
}
public void ServiceMethod1(string a, object b)
{
_serviceBL.ServiceMethod1(a, b);
}
public int ServiceMethod2(int a, int b)
{
return _serviceBL.ServiceMethod2(a, b);
}
}
因为这个变得相当重复的,我不知道是否有我可以根据合同自行发出服务方法。我希望的代码可能是这个样子:
public abstract class MagicServiceBase<T>
{
protected dynamic InterfaceImplementor { get; }
public MagicServiceBase()
{
// Magic that makes the methods defined in T real.
}
}
public class Service : MagicServiceBase<IService>, IService
{
protected override dynamic InterfaceImplementor
{
get
{
return new ServiceBL();
}
}
}
有没有一种方法来创建此,还是我只是想成为合理懒得?
我认为服务和业务层听起来像同义词。其中一个是不必要的。 – duffymo 2013-04-10 12:38:03
@duffymo:我一般听说把你的服务契约实现与实际的业务逻辑分开是一件好事。 – zimdanen 2013-04-10 12:51:28
你没有分开任何东西;听起来像通过。我看不到任何事务或其他任何东西来区分您的自动生成的服务层。为什么生成无意义的代码?我有基于接口的服务,但我给他们一些有意义的事情。我让他们成为工作单位的所有者和编排者。 – duffymo 2013-04-10 12:52:33