2017-07-20 41 views
6

W tej chwili buduję wiele małych API w pracy. Wiele z tych projektów ma pewną podstawową logikę kontrolerów. Czy jest jakiś sposób dodania ich do pakietu nuget i używania ich podczas uruchamiania?
Np. jak dodanie MVC:Udostępnianie domyślnego kontrolera MVC

IApplicationBuilder app;  
....  

app.UseMvc; 
app.UseBasicApiVersionController(); 

Chodzi o to, że mamy punkt końcowy wersji we wszystkich naszych mikrousługach.
Np
http://url/version
powraca { "wersja": "1.0.0"}
Jak chciałbym zrobić to w pakiet Nuget?
Czyli wszyscy programiści muszą tylko dodać 1 linię kodu, aby dodać ten punkt końcowy do swojej mikro usługi? Używamy rdzenia dotnet.
nie pomagają stworzyć pakiet Nuget to samo :)

Domyślam dla podręczny jest coś podobnego do tego:

public static IApplicationBuilder UseBasicApiVersionController(this IApplicationBuilder app) 
    { 
     if (app == null) 
     throw new ArgumentNullException("app"); 

     ..... // What should I do? 

     return app; 
    } 

* Edycja:
Jeśli dodać sterownik do Nuget pakiet projekt zostanie automatycznie wykryty. Ale to nie jest funkcja, której pragnę.
Mogę mieć 10 usług, które wymagają tego kontrolera. O ile 1-2 usługi, które tylko chcą, to inna logika kontroli wersji. Na przykład. Aplikacja skierowana do klienta nie powinna mieć punktu końcowego "/ version".
Dlatego chcę, aby podczas uruchamiania używać app.Use.SzablokowanieAiagnostyka();

+1

Jako alternatywne podejście: co z tworzeniem domyślnego szablonu projektu z domyślnymi kontrolerami. Lub po prostu projekt. Możesz wtedy po prostu sklonować repozytorium i zacząć od wszystkiego, czego potrzebujesz. Możesz nawet rozwidlić/rozgałęzić ten projekt, aby stworzyć różne punkty początkowe dla różnych rodzajów mikrousług. – Marco

+0

@Marco> Pomyślałem o tym. Ale jeśli w przyszłości zmienimy logikę działania punktu końcowego wersji, będziemy musieli przejść do wszystkich naszych projektów i je naprawić. Np. W tej chwili potrzebujemy tylko numeru wersji. Później możemy potrzebować etykiety: Aplha/beta/release. Byłoby miło po prostu mieć pakiet nuget do aktualizacji zamiast otwierania wszystkich starszych projektów i dodawać nową logikę dla domyślnego kontrolera. – Kiksen

+0

Można również użyć iniekcji zależności. Możesz podać klasę formatowania adresów URL, która akceptuje wszystkie dynamiczne dane potrzebne do utworzenia poprawnego adresu URL klienta. – Silvermind

Odpowiedz

0

Jeśli jest przeznaczona tylko dla wersji, można dodać wspólne rozszerzenie lub kawałek oprogramowania pośredniego, które zwraca wersję.

public class VersionMiddleware: OwinMiddleware 
{ 
    private static readonly PathString Path = new PathString("/version"); 
    private OwinMiddleware Next; 

    public VersionMiddleware(OwinMiddleware next) : base(next) 
    { 
     Next = next; 
    } 

    public async override Task Invoke(IOwinContext context) 
    { 

     if (!context.Request.Path.Equals(Path)) 
     { 
      await Next.Invoke(context); 
      return; 
     } 

     var version = Assembly.[HowToGetYourVersionAsAnObject] 

     context.Response.StatusCode = (int)HttpStatusCode.OK; 
     context.Response.ContentType = "application/json"; 
     context.Response.Write(JsonConvert.SerializeObject(responseData)); 
    } 
} 
+0

Idea jest dynamiczna i używana do innych rzeczy niż tylko wersja. Jak opisano w komentarzu. Jeśli w przyszłości chciałbym zwrócić wersję + etykiety. Lub cały widok maszynki Razor. – Kiksen

+0

Powracanie widoku maszynki do golenia może być innej możliwości. Pozostałe to tylko niektóre komponenty oprogramowania pośredniego. – mhermann

+0

Ale masz rację. Nie jest tak wszechstronny jak kontrolery. Pytanie brzmi, czy jest to wymaganie, czy też projekt dla jakiegoś potencjalnego wymogu przyszłości. – mhermann