我在Service Fabric下运行了7项服务。我决定创建一个通用的OwinCommunicationsListener类,因为代码非常通用。
我注意到Service Fabric的模板将启动类(配置管道)设置为静态类,无状态服务类将其作为操作传递
internal sealed class WebService : StatelessService
{
public WebService(StatelessServiceContext context)
: base(context)
{ }
/// <summary>
/// Optional override to create listeners (like tcp, http) for this service instance.
/// </summary>
/// <returns>The collection of listeners.</returns>
protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
return new ServiceInstanceListener[]
{
new ServiceInstanceListener(serviceContext => new OwinCommunicationListener(Startup.ConfigureApp, serviceContext, ServiceEventSource.Current, "ServiceEndpoint"))
};
}
}
如果我需要做DI,我需要将这些对象传递给启动类。从模板中,我能看到的唯一方法是在OwinCommunicationsListener中设置这些对象或将参数传递给OwinCommunicationsListener - 其中任何一个都意味着OwinCommunicationsListener不那么通用。
我注意到在WordCount示例中,他们使用了正常的启动类,并将对它的引用传递给了OwinCommunicationsListenter。这样,ServiceClass可以将一些对象传递给Startup,它可以用于DI,而OwinCommunicationsListener可以保持通用。
public class WordCountWebService : StatelessService
{
public WordCountWebService(StatelessServiceContext context)
: base(context)
{
}
/// <summary>
/// Creates a listener for Web API with websockets.
/// </summary>
/// <returns>The OWIN communication listener.</returns>
protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
return new[]
{
new ServiceInstanceListener(initParams => new OwinCommunicationListener("wordcount", new Startup(MyDIObject), initParams))
};
}
}
如果我将无状态服务类视为大脑而将OwinCommunicationsListener类视为由多个服务共享的通用帮助程序,那么我似乎应该与wordcount示例使用相同的路由并具有非静态启动类。这种方法有什么缺点吗?我想知道为什么模板不会使用这种方法,当微服务的想法是我们将有很多这样的,这样的通用脚手架可以提高维护和可靠性。
答案 0 :(得分:2)
wordcount示例是我推荐的。没有我不知道的缺点。
你看过ASP.NET Core吗?使用内置DI的IWebHost可以更轻松。以下是一个示例:https://github.com/vturecek/service-fabric-xray/blob/master/src/xray.Data/DataService.cs