My domain classes that have one-to-many mappings generally take the following form (untested code):
public Customer Customer
{
// Public methods.
public Order AddOrder(Order order)
{
_orders.Add(order);
}
public Order GetOrder(long id)
{
return _orders.Where(x => x.Id).Single();
}
// etc.
// Private fields.
private ICollection<Order> _orders = new List<Order>();
}
The EF4 code-only samples I've seen expose a public ICollection when dealing with one-to-many relationships.
Is there a way to persist and restore my collections with exposing them? If not, it would appear that my domain objects will be designed to meet the requirements of the ORM, which seems to go against the spirit of the endeavour. Exposing an ICollection (with it's Add, etc. methods) doesn't seem particularly clean, and wouldn't be my default approach.
Update
Found this post that suggests it wasn't possible in May. Of course, the Microsoft poster did say that they were "strongly considering implementing" it (I'd hope so) and we're half a year on, so maybe there's been some progress?
Another way to accomplish this would be to create an associated interface for each of your POCOs to expose only what you want outside of the persistence/domain layers. You can also interface your DbContext class to also hide and control access to the DbSet collections. As it turns out, the DbSet properties can be protected, and the model builder will pick them up when it's creating tables, but when you try to access the collections they will be null. A factory method (in my example, CreateNewContext) can be used instead of the constructor to get the interfaced DbContext to conceal the DbSet collections.
There's quite a bit of extra effort in coding, but if hiding implementation details within the POCOs is important, this will work.
UPDATE: It turns out you CAN populate DBSets if they are protected, but not directly in the DBContext. They can't be aggregate roots (i.e. accessibility of the entity has to be through a collection in one of the public DBSet entities). If hiding the implementation of DBSet is important, the interface pattern I've described is still relevant.
I found that whatever was done, EF requires the
ICollection<T>
to be public. I think this is because when the objects are loaded from the database, the mapping looks for a collection property, gets the collection and then calls theAdd
method of the collection to add each of the child objects.I wanted to ensure that the addition was done through a method on the parent object so created a solution of wrapping the collection, catching the add and directing it to my preferred method of addition.
Extending a
List
and other collection types was not possible because theAdd
method is not virtual. One option is to extendCollection
class and override theInsertItem
method.I have only focussed on the
Add
,Remove
, andClear
functions of theICollection<T>
interface as those are the ones that can modify the collection.First, is my base collection wrapper which implements the
ICollection<T>
interface The default behaviour is that of a normal collection. However, the caller can specify an alternativeAdd
method to be called. In addition, the caller can enforce that theAdd
,Remove
,Clear
operations are not permitted by setting the alternatives tonull
. This results inNotSupportedException
being thrown if anyone tries to use the method.The throwing of an exception is not as good as preventing access in the first place. However, code should be tested (unit tested) and an exception will be found very quickly and a suitable code change made.
Given that base class we can use it in two ways. Examples are using the original post objects.
1) Create a specific type of wrapped collection (For example,
List
) public class WrappedListCollection : WrappedCollectionBase, IList { private List innerList;This can then be used:
2) Give a collection to be wrapped using
which can be used as follows:
{ public ICollection Orders {get { return _wrappedOrders; } } // Public methods.
There are some other ways to call the
WrappedCollection
constructors For example, to override add but keep remove and clear as normalI agree that it would be best if EF would not require the collection to be public but this solution allows me to control the modification of my collection.
For the problem of preventing access to the collection for querying you can use approach 2) above and set the WrappedCollection
GetEnumerator
method to throw aNotSupportedException
. Then yourGetOrder
method can stay as it is. A neater method however may be to expose the wrapped collection. For example:Then the call in the
GetOrder
method would becomeIf you change the name of your
_orders
collection to the name of the orders table in your database, this should work. EF maps table/field names to collections/properties by convention. If you want to use a different name you could edit the mappings in the edmx file.AFAIK you can just leave the private modifier as it is. Collections do not need to be public.