I have multiple REST-ful APIs that I'm using as my "back-end". I also have multiple web apps (.NET MVC). These web apps make calls to the APIs for data. So, an object being returned by an API will be the same as the object being expected on the web app side (serialized from JSON of course).

For example, if my web app makes a call to an API for a Customer object, that same object will be used across both the API and web app projects.

So, the question is, how do you manage this scenario (create NuGet packages for shared objects/interfaces, duplicate code, etc.)?


It it is just a DTO with the same properties I would strongly suggest to just copy it between the server and client.

See also this stackoverflow answer that has the same conclusion

The reason is in reality once you have a wire format it is very difficult to change once the system is in production. Unless you deploy server and client at the same time which will include increased risk and downtime. That means normally we cannot just rename fields. A rename will include adding a new field - then at a later release delete the unused field. With this in mind we see that we gain nothing from sharing the DTO in a nuget or shared assembly.

  • Thanks for the response. This is the way I was leaning also. I don't like the duplicate code, but it's propably the way to go. Adding a package for each API's DTOs and Interfaces seems like it would add more complexity to deployments than it would be worth. – lioneltwain Apr 17 at 23:01

Most commonly you would need an assembly that defines the DTO objects that is shared between the front end and the back end. That doesn't necessarily have to be a NuGet package. It can simply be another project in the same solution that your other projects reference directly.

  • Each API and Web App is in its own solution. That's why I was considering NuGet packages. But that seems like overkill as you would need a NuGet per API. – lioneltwain Apr 16 at 17:55
  • If you have your own NuGet repository (like Sonatype Nexus, or Microsoft Team Foundation Server) then it's perfectly fine to have a NuGet package. It's not worth it necessarily to share that code with the whole world. – Berin Loritsch Apr 16 at 20:23
  • Sorry, I would be using an internal NuGet repository for packages. I should have specified. – lioneltwain Apr 16 at 20:45

I like the Nuget approach best, and more so in conjunction with CQS (A web api only exposing a ExecuteQuery and ExecuteCommmand and than a shared contracts library with all the command / queries)

But you can also use Swashbuckle (Swagger).

Install-Package Swashbuckle.AspNetCore

And add

services.AddSwaggerGen(c =>
    c.SwaggerDoc("v1", new Info { Title = "My API", Version = "v1" });

More info https://docs.microsoft.com/en-us/aspnet/core/tutorials/getting-started-with-swashbuckle?view=aspnetcore-2.2&tabs=visual-studio

You can now generate a swagger client for example with NSwag (Covered in above article).

Again, this is just posted as an alternative, personally I like the shared library approach better


In addition to the Berin's answer.

how do you manage this scenario (create NuGet packages for shared objects/interfaces, duplicate code, etc.)?

If the coupling between the back-end and its clients is problematic for you (no matter the reason) or both back-end and front-end don't share the same stack, then these DTOs should be "duplicated". Alternatively, I use to advocate for TolerantReaders so that, both sides can deal with changes with a higher degree of tolerance. Just remember that at the boundaries, applications are not OOP. This allows you to relax the needs for SOLID.

If none of the above scenarios affects you, then Berin's answer applies. If at the end of this, you end up with a new library, just follow a good versioning strategy. For example, Semantic Version.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.