Visual Studio 2015 Update 2提供了一個用於在服務結構中創建基於owin的控制器的模板。創建的結構向您展示了一個無狀態的可靠服務，並將基於owin的控制器顯示爲2個不同的C＃類。這工作。在這種情況下，可靠的服務類只需註冊一個http偵聽器，所有的調用都將被路由到控制器類。在某種程度上，無狀態的可靠服務一旦創建就會脫離圖像，並且僅在服務啓動時纔有用。服務結構中的可靠服務是否也可以直接用於RESTful（而不是單獨的基於owin的控制器）？
我期待看到可靠的服務和基於owin控制器，一個相同的。目前的結構看起來像一個補丁工作。
如果我改變無狀態的可靠的服務於有狀態可靠的服務，我真的不能做任何事情與狀態服務，因爲我的請求路由到控制器。如果我要在狀態管理器中與控制器進行交互，那麼我必須獲得對有狀態服務的引用，然後完成我的工作。感到尷尬。
是否有這樣做的更清潔的方式？
的服務是您的應用程序容器。服務基類（StatefulService和StatelessService）是您的應用程序的入口點。你可以直接在這些類中進行派對，並讓你的所有代碼都在那裏，或者你可以使用這個入口點來引導一些其他的應用程序框架，比如ASP.NET MVC或者Reliable Actors等。 Service Fabric通過服務基類（例如，ServiceContext，用於有狀態服務的IReliableStateManager等）提供所有平臺依賴關係，並且如果這是您的代碼所在的位置，您可以直接在這些類中使用它們，或者可以傳遞這些依賴關係以及其他一些應用程序框架。
對於ASP.NET，我們使用該服務來引導基於OWIN的Web服務器（Katana，Kestrel，WebListener），然後向其提供應用程序中間件（MVC，StaticFiles等）。然後，您可以使用您最喜愛的依賴注入框架（Unity，Autofac，Ninject或ASP.NET Core的內置依賴注入框架）將所有平臺依賴關係傳遞給中間件。
這裏是一個有狀態的服務，統一性與武士刀做到這一點的例子：https://github.com/Azure-Samples/service-fabric-dotnet-getting-started/tree/master/Services/WordCount/WordCount.Service
想着想着可靠的服務項目作爲主機（如主機服務過程）。你對容器的使用更適合這種結構。謝謝。 – Raghu
這些天大多數術語都是重載的，但是當我們談論「主機」時，我們指的是承載服務實例或副本的進程，當我說「容器」時，我不是指Docker。 –