Architecture: entity framework Web Api

Question

I'm creating a web api program using entity framework. So as the basis, I have an sql server database which I'm connected to with entity framework trought my web api program. Using an add-on for entity framework, I'v generated classes according to my database tables. However i don't want to use these classes for my webservices because I don't need to display some of the attributes generated by the entity framework and little bit tricky with all the proxies problems. These attributes are especially generated because of the foreign keys. As below, for this generated class, I don't need to display "Societe" object and "Utilisateur" object:

 public partial class FonctionnalitePerUser
{
    public int FonctionUserLngId { get; set; }
    public int FonctionUserLngUserId { get; set; }
    public int FonctionUserLngSocieteId { get; set; }
    public virtual Societe Societe { get; set; }
    public virtual Utilisateur Utilisateur { get; set; }

}

I would need some advice to avoid displaying that entities in my webservices. I was thinking about 3 possibilities:

• As it's a partial class, I might create an other partial class with the same name where I put the attributes that I need and override the constructor.
• I might inherit a custom class from that one to override the constructor in order to get one structured as I need.
• I might create Management classes with functions that create the perfect objects that I need for my webservices. I mean functions that convert "FonctionnalitePerUser" object to "FonctionnalitePerUserCustom" objects.

These are the 3 solutions that I've found. In order to get the best performance, I was wondering if anyone can give me some advise about that or either propose some other solutions. Thanks in advance

Answer 1

If your using Newtonsoft Json.NET which I think is the default in MVC5 then you can attribute your properties to tell newtonsoft what to serialize and what to ignore.

public class Car
{
  // included in JSON
  public string Model { get; set; }
  public DateTime Year { get; set; }
  public List<string> Features { get; set; }

  // ignored
  [JsonIgnore]
  public DateTime LastModified { get; set; }
}

or if you have more properties you want to ignore than you want to serialize you can do this:

[DataContract]
public class Computer
{
  // included in JSON
  [DataMember]
  public string Name { get; set; }
  [DataMember]
  public decimal SalePrice { get; set; }

  // ignored
  public string Manufacture { get; set; }
  public int StockCount { get; set; }
  public decimal WholeSalePrice { get; set; }
  public DateTime NextShipmentDate { get; set; }
}

this information was taken from here .

Answer 2

In general, it is often useful to expose a different type of object for a web service API than for persistence. This is for exactly the reason you state: because you don't need to expose all of that persistence stuff to the rest of the world (clients).

Usually, you would map the information that you want to expose from your persistence model (EF entities etc) to a view model object (or DTO).

So, I would say your option 3 is on the right track.

I might create Management classes with functions that create the perfect objects that I need for my webservices. I mean functions that convert "FonctionnalitePerUser" object to "FonctionnalitePerUserCustom" objects

There are several tools out there that help with the converting or mapping of the objects. One is AutoMapper which will map by convention. This can save a lot of mapping code.