0

Situation:

  • Server side in a Web API controller I got a model class, lets call it MyNamespace.MyData, that in addition to properties also has business logic functions like a bool CanEditThis() method.
  • With Visual Studio 2017 I use "Add"->"REST API Client" to generate client side code to call the Web API methods and return data, but this generates a new model class like ClientNamespace.MyData for the client (without functions), instead of detecting there already is a useable model class MyNamespace.MyData (with funcitons).
  • The model classes used server side are defined in their own project and available in a DLL for both client and server side code (used this setup for WCF but wanted to implement new features via Web API).

How can I use the same model class on both ends?

Any magic property to add to the swagger/OpenAPI definition so AutoREST generated code knows to reuse a class model instead of making a new?

Or do I have to choose between a) duplicating the code of the partical class MyData both in server-side and client-side projects or b) having utility functions to convert the returned IList<ClientNamespace.MyData> to IList<MyNamespace.MyData>?

Allan K.
  • 49
  • 8
  • Similar question: https://github.com/Azure/autorest/issues/1730 Seams like it is in progress but not yet supported. – Allan K. Feb 26 '18 at 09:16

1 Answers1

-1

The best solution I could imagine so far:

Server side model class MyNamespace.MyData get static method:

public static bool GetCanEditThis(arg) {...}

plus a getter method that is decorated to be ignored by Web API/swagger:

[JsonIgnore] public bool CanEditThis { get { return CanEditThis(this.arg) } }

Client side model class ClientNamespace.MyData get a separate file with a partial class to extend the auto generated class which contains:

public bool CanEditThis { get { return MyNamespace.MyData.CanEditThis(this.arg) } }

That way the business logic is only written once, and the two model classes just both need to call the same method with their own properties as arguments since the business logic function does not have access to actual data otherwise.

Allan K.
  • 49
  • 8
  • It solves MY problem - a setup for rapid development with AutoREST to regenerate client code to call server API as we rapidly add new features and change the API. The alternative would be to hand code everything produced by AutoREST in order to force reuse of the same model class and code on both ends. That hand coding would in effect become your nice standard library, but it is out of scope for an API that is only used by one client and which rapidly changes. – Allan K. Feb 26 '18 at 14:32
  • That was my original question: How to avoid duplicate code server side and client side. Making a client side API on top of AutoREST would not solve that the same model objects is not available serve side. Having duplicate properties that call the same centralized code was the closest I could come. – Allan K. Mar 01 '18 at 13:21
  • I can only make the minimal solution I described above. I don't see how to do anything else without looping project references (unless you make a library that does not know anything about either of the model classes and only takes plain parameters, but that fails to hide the changing business logic I am trying to protect with an object oriented design). Please try to describe the setup you imagine, with the projects and model classes you want to create/auto-generate, as a new answer, instead of just saying it is not difficult. – Allan K. Mar 06 '18 at 09:32
  • Odd - the person who downvoted my answer and whom I was arguing with have disappeared, deleting all his comments and his own answer, so the above 'discussion' no longer makes any sense... – Allan K. Apr 26 '18 at 09:04