В моей компании наши сервисные реализации в основном просто передают вызов бизнес-уровню, который выполняет фактическую обработку. Так, например, если у нас есть контракт на обслуживание, который выглядит следующим образом:Динамическое создание динамической реализации
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
@duffymo: Я, как правило, хорошо разбираюсь в том, чтобы отделить реализацию вашего сервисного контракта от реальной бизнес-логики. – zimdanen
Вы ничего не отделили; звучит как проход. Я не вижу никаких транзакций или чего-либо еще, чтобы отличить ваш автоматически сгенерированный сервисный уровень. Зачем генерировать бессмысленный код? У меня есть интерфейсные сервисы, но я даю им что-то значимое. Я делаю их владельцами и оркестрами подразделений. – duffymo