EntityFramework 和 ReadOnlyCollection

Question

I use EntityFramewotk and code first approach. So, I describe my model like this:

class Person
{
    public long Id { get;set; }
    public string Name { get;set; }
    public ICollection<Person> Parents { get;set; }
}

But, my domain logic don't allow to modify Parents collection (add, delete), it must be readonly (just for example). EntityFramework requires all Collections have ICollection<T> interface, and it has Add method (to materialize results) and Remove method, and others. I can create my own collection with explicit implementation of interface:

public class ParentsCollection : ICollection<Person>
{
    private readonly HashSet<Person> _collection = new HashSet<Person>();
    void ICollection<Person>.Add(Person item)
    {
        _collection.Add(item);
    }

    bool ICollection<Person>.Remove(Person item)
    {
        return _collection.Remove(item);
    }

    //...and others
}

This hides Add and Remove methods, but does not protect at all. Because I can always cast to ICollection and call prohibited method.

So, my question is:

• Is there a way to work with read-only collections in EntityFramework?

Answer 1

You can expose private collection properties to EF, allowing for mapping and querying, while still keeping your domain object's members and relationships properly encapsulated. It's a bit messy, but it works:

public class Customer
{
    public int Id { get; set; }
    public string Name { get; set; }

    public IEnumerable<Order> Orders
    {
        get { return _orders.AsEnumerable(); }
    }

    private List<Order> _orders { get; set; }

    public Customer()
    {
        _orders = new List<Order>();
    }

    public static Expression<Func<Customer, ICollection<Order>>> OrderMapping
    {
        get { return c => c._orders; }
    }
}

Mapping then uses:

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);
    modelBuilder.Entity<Customer>().HasMany(Customer.OrderMapping);
}

This approach is described further here: http://ardalis.com/exposing-private-collection-properties-to-entity-framework

Answer 2

In EF Core, you can encapsulate collections and achieve true domain modeling by using backing fields . So, you can define your collection as a private field and expose it as a public readonly property like below as _parents and Parents .

class Person
{
    public long Id { get;set; }
    public string Name { get;set; }
    private List<Person> _parents = new List<Person>();
    public IReadOnlyCollection<Person> Parents => _parents.AsReadOnly();
    public void AddParent(Parent parent){
        _parents.Add(parent); 
    }
}

As you can see, Parents is a read-only collection and consumers are not allowed to modify it.

Note that _parents is discovered as a backing-field by ef core's convention.

Answer 3

Short answer: no . And it would be strange that you could that ( well, NHibernate can set private class fields and this means that you can expose it using a public property encapsulating the field as read-only collection... well, you can workaround this situation in EF too: Entity Framework Many to many through containing object . BTW, I wouldn't suggest you this approach, because how could you add new parents if it's a private property? )

Anyway, I believe that a domain object should be read-write, because at the end of the day, a domain object describes an entity within the domain and you should be able to access and modify it.

An alternate solution is designing an interface to expose Parents as IReadOnlyList<Person> , and also an IPerson with all Person members excepting Parents , and return Person as IPerson :

public interface IHasParents
{
    IReadOnlyList<Person> Parents { get; }
}

public interface IPerson : IHasParents
{
    long Id { get; set; }
    string Name { get; set; }
}

And implement IPerson implicitly on Person excepting Parents that would be implemented explicitly . When you need to return a Person somewhere, you return IPerson instead of Person :

public IPerson CreatePerson(string name, IEnumerable<Persons> parents)
{
    Person person = new Person { Name = name, Parents = parents };

    // Persistence stuff

    return person;
}

You can argue that you may be able to downcast IPerson to Person , but at this point I would answer telling you that you need to follow your own coding conventions: if you defined that you never return Person but IPerson then I would do it this way in the entire code base, and if you need a write-capable Parents property, then you return Person instead (and you avoid a cast later!).

Answer 4

Well, there is a way. It ain't pretty as it adds extra stuff on your domain model, but I just checked and it works.

All credits go to Owen Craig.

http://owencraig.com/mapping-but-not-exposing-icollections-in-entity-framework/

Example in a nut shell

Imagine we have existing model with Organization => Employees already set up.

To apply this technique, we need to change Organization model a bit:

// this is the main collection that will be persisted, mark it as protected
protected virtual ICollection<Employee> EmployeesInternal { get; private set; } = new List<Employee>();

// this will expose collection contents to public, seemingly unneccessary `Skip` statement will prevent casting back to Collection
public IEnumerable<Employee> Employees => EmployeesInternal.Skip(0);

// this is property accessor that will be used to define model and/or in `Include` statements, could be marked as internal if your domain/persistance/services are in the same assembly
public static Expression<Func<Organization, ICollection<Employee>>> EmployeeAccessor = f => f.EmployeesInternal;

Change fluent config in your database context:

modelBuilder.Entity<Organization>().HasMany(Organization.EmployeeAccessor).WithRequired();

Change any Include statements in case you are not using LazyLoading

var organizations = organizationRepository.GetAll().Include(Organization.EmployeeAccessor)

Happy DDD!

Answer 5

If you, like me, are stuck using .Net Framework for a while longer, you can make this work in Entity Framework 6.x. It isn't pretty, and you only get runtime write protection on your readonly collections, but here is one way to go about it.

I don't recommended this, but if you must adhere so strongly to DDD, and only manipulate collections through Roots / Aggregates, well, don't say I didn't warn you...

NOT RECOMMENDED : http://edo-van-asseldonk.blogspot.com/2012/03/readonly-collections-with-entity.html

Our ReadonlyList wound up a bit more involved. To fully protect against changes (including Add, Insert, Remove, and their collection-based siblings) you need something like this:

/// <remarks>
///     This class should be removed after migration to EF Core, which supports IReadonlyCollection.
/// </remarks>
/// <summary>
///     Represents a strongly typed read-only list of objects that can be accessed by index. Provides methods to search,
///     sort, and manipulate lists.
/// </summary>
/// <typeparam name="T">The type of elements in the list.</typeparam>
public class ReadonlyList<T> : List<T>
{
    public ReadonlyList(IEnumerable<T> collection)
        : base(collection)
    {
    }

    /// <summary>
    /// Not supported.
    /// </summary>
    public new void Add(T item)
    {
        base.Add(item);
        throw new NotSupportedException(GetNotSupportedExceptionMessage(nameof(Add)));
    }

    /// <summary>
    /// Not supported.
    /// </summary>
    public new void AddRange(IEnumerable<T> collection)
    {
        throw new NotSupportedException(GetNotSupportedExceptionMessage(nameof(AddRange)));
    }

    /// <summary>
    /// Not supported.
    /// </summary>
    public new void Insert(int index, T item)
    {
        throw new NotSupportedException(GetNotSupportedExceptionMessage(nameof(Insert)));
    }

    /// <summary>
    /// Not supported.
    /// </summary>
    public new void InsertRange(int index, IEnumerable<T> collection)
    {
        throw new NotSupportedException(GetNotSupportedExceptionMessage(nameof(InsertRange)));
    }

    /// <summary>
    /// Not supported.
    /// </summary>
    public new void Remove(T item)
    {
        throw new NotSupportedException(GetNotSupportedExceptionMessage(nameof(Remove)));
    }

    /// <summary>
    /// Not supported.
    /// </summary>
    public new void RemoveAll(Predicate<T> match)
    {
        throw new NotSupportedException(GetNotSupportedExceptionMessage(nameof(RemoveAll)));
    }

    /// <summary>
    /// Not supported.
    /// </summary>
    public new void RemoveAt(int index)
    {
        throw new NotSupportedException(GetNotSupportedExceptionMessage(nameof(RemoveAt)));
    }

    private string GetNotSupportedExceptionMessage(string memberName)
    {
        return $"Member {memberName} is not supported in {nameof(ReadonlyList<T>)}.";
    }
}