I see two distinct subjects in your question:

• How to manage circular references when serializing to JSON?
• How safe is it to use EF entities as model entities in you views?

Concerning circular references I’m sorry to say that there is no simple solution. First because JSON cannot be used to represent circular references, the following code:

var aParent = {Children : []}, aChild  = {Parent : aParent};
aParent.Children.push(aChild);
JSON.stringify(aParent);

Results in: TypeError: Converting circular structure to JSON

The only choice you have is to keep only the composite –> component part of the composition and discard the “back navigation” component –> composite, thus in you example:

class parent
{
    public List<child> Children{get;set;}
    public int Id{get;set;}
}
class child
{
    public int ParentId{get;set;}
    [ForeignKey("ParentId"), ScriptIgnore]
    public parent MyParent{get;set;}
    public string name{get;set;}
}

Nothing prevents you from recomposing this navigation property on your client side, here using jQuery:

$.each(parent.Children, function(i, child) {
  child.Parent = parent;  
})

But then you will need to discard it again before sending it back to the server, for JSON.stringify won’t be able to serialize the circular reference:

$.each(parent.Children, function(i, child) {
  delete child.Parent;  
})

Now there is the issue of using EF entities as your view model entities.

First EF is likely to using Dynamic Proxies of your class to implement behaviors such as change detection or lazy loading, you have to disable those if you want to serialize the EF entities.

Moreover using EF entities in the UI can be at risk since all the default binder will mapping every field from the request to entities fields including those you did not want the user to set.

Thus, if you want you MVC app to be properly designed I would recommended to use a dedicated view model to prevent the “guts” of your internal business model from being exposed to the client, thus I would recommend you a specific view model.

A simpler alternative to attempting to serialize the objects would be to disable the serialization of parent/child objects. Instead, you could make a separate call to fetch the associated parent/child objects as and when you need them. This may not be ideal for your application, but it’s an option.

To do this, you could set up a DataContractSerializer and set the DataContractSerializer.PreserveObjectReferences property to ‘false’ in the constructor of your data model class. This specifies that the object references should not be preserved on serializing the HTTP responses.

Examples:

Json format:

var json = GlobalConfiguration.Configuration.Formatters.JsonFormatter;
json.SerializerSettings.PreserveReferencesHandling = 
    Newtonsoft.Json.PreserveReferencesHandling.None;

XML format:

var xml = GlobalConfiguration.Configuration.Formatters.XmlFormatter;
var dcs = new DataContractSerializer(typeof(Employee), null, int.MaxValue, 
    false, /* preserveObjectReferences: */ false, null);
xml.SetSerializer<Employee>(dcs);

This means that if you fetch an item which has child objects referenced, the child objects won’t be serialized.

See also the DataContractsSerializer class.

JSON serializer that deals with Circular References

Here is an example custom Jackson JSONSerializer that deals with circular references by serializing the first occurrence and storing a *reference to the first occurrence on all subsequent occurrences.

Dealing with Circular References when Serializing objects with Jackson

Relevant partial snippet from the above article:

private final Set<ObjectName> seen;

/**
 * Serialize an ObjectName with all its attributes or only its String representation if it is a circular reference.
 * @param on ObjectName to serialize
 * @param jgen JsonGenerator to build the output
 * @param provider SerializerProvider
 * @throws IOException
 * @throws JsonProcessingException
 */
@Override
public void serialize(@Nonnull final ObjectName on, @Nonnull final JsonGenerator jgen, @Nonnull final SerializerProvider provider) throws IOException, JsonProcessingException
{
    if (this.seen.contains(on))
    {
        jgen.writeString(on.toString());
    }
    else
    {
        this.seen.add(on);
        jgen.writeStartObject();
        final List<MBeanAttributeInfo> ais = this.getAttributeInfos(on);
        for (final MBeanAttributeInfo ai : ais)
        {
            final Object attribute = this.getAttribute(on, ai.getName());
            jgen.writeObjectField(ai.getName(), attribute);
        }
        jgen.writeEndObject();
    }
}

The one solution I have come up with is to create “View” Models. I
create simple versions of the database models that do not include the
reference to the parent class. These view models each have method to
return the Database Version and a constructor that takes the database
model as a parameter (viewmodel.name = databasemodel.name). This
method seems forced although it works.

Sending out the bare minimum of data is the only correct answer. When you send out data from the database, it usually doesn’t make sense to send out every single column with all the associations. The consumers shouldn’t need to deal with database associations and structures, that is for databases. Not only will this save bandwidth but it’s also much easier to maintain, read and consume. Query the data and then model it for what you actually need to send out eq. the bare minimum.

.Include(x => x.TableName ) not returning relationships (from principal table to dependent table), or only returning one row of data, FIX HERE:

https://stackoverflow.com/questions/43127957/include-not-working-in-net-core-returns-one-parent

Also, in Startup.cs make sure you have this at the top:

using Microsoft.EntityFrameworkCore; 
using Newtonsoft.Json; 
using Project_Name_Here.Models;