Domain Model classes split into a seperate assembly

Question

I am creating a webAPI using the webAPI2.
I have created some domain model classes which are part of the models folder inside the webAPI project.
This is the DataRequest Model class

public class DataRequest 
{
    Field1
    Field2...
}

The Controller class and Action method are below.

  [RoutePrefix("api/Data")]
  public class DataController : ApiController
  {
      [Route("")]
      [HttpPost]
     public IHttpActionResult Post(DataRequest request)
     {
     }
  }

And the data request body issued in postman in json

{
   Field1:"Some Value",
   Field2: "Some Value"
}

The model binding works perfectly and I get values in the POST action method for field1 and field2.
I have a separate project with helper methods and I want to extend this project by adding some business logic with the Data Request class. Hence I have created a separate project with models and added that project as reference to helpers and api projects.
The project compiles successfully with this setup. But when I issue a request in Postman, the Action method gets called but I get null for all the fields in the request parameter.
Googling pointed me to some links which explain loading controller classes from separate assembly but there is no reference to load models from separate assembly.

Is this allowed and if yes, can anyone let me know how to get this working.

score 0 · Accepted Answer · answered Jan 03 '20 at 06:01

Finally, I got this solved. I had [Serializable] attribute for the DataRequest class and Field2 of the DataRequest class is defined as type of List<>. After going through this stack over flow response, I removed the [Serializable] attribute from DataRequest class which gave me an error that the type List<> can not be cast to System.Array.
After this, I changed the Field2 type from list to Array and it worked.
Initially, when I had models defined in the API Project itself, I received an error when the Field2 is declared as Array type. This made me ignore the discrepancy in type of the Field2 but finally it turned out to be culprit.

Domain Model classes split into a seperate assembly

1 Answers1