Share classes vs. swagger generated classes

Viewed 108

I have an asp.net/Blazor VS solution with three projects,

  1. Shared
  2. asp.net core apis
  3. Blazor webassembly.

I created bunch of classes in Shared project and from the other two projects, made a reference to the Shared project. All is good so far.

Then I used Swagger UI to generated stubs for me so I can interact with the remote APIs. Swagger UI created the Service.cs and Contract.cs which is great. The problem is that Contract.cs has redefined the classes that I have declared in Shared projects under it's own namespace. Now I don't know which to use and which to import. If I use my own Shared classes, then I won't be able to use the APIs from swagger in Service.cs without casting. If I modify Contract.cs, then all my changes will be lost the next time I run Swagger UI.

This also resulted in having two DBContext - 1) the one I defined and 2) The one that swagger defined. Now every time I want to do something, I also have to use --context parameter on the command line to specify which DBContext to use.

The question is how can I use my own classes yet use swagger to make life easy in terms of talking to the remote APIs? What is the best practice here?

1 Answers

When you want to use Swagger (client side) then you shouldn't reference the Shared project. The swagger claases is what you get/want then.

But you don't need Swagger in Blazor. The opportunity to share DTO classes in Shared is one of the highlights of Blazor.

If you want some help with the boilerplate stuff on the Client then there are options like refit. See this blog about it.

Related