daelmo wrote:
Hi Richard,
There is a better way for sure.
- Did you already fetch the entities and want to filter them in-memory?
- Why Enumerable<...>?
- If possible, could you please explain your scenario in terms of a Northwind case? For example: Order <-> (m:n) <-> Product, or something like that. Coz I lost a little bit in the intention of your code.
I used IEnumerable here because that's what I want to do, but really right now, it's an:
public partial class EntityCollection<TEntity> : EntityCollectionBase2<TEntity>
where TEntity : EntityBase2, IEntity2
It shouldn't make a difference really, though, unless EntityCollectionBase2 has something I can use to do what I want that IEnumerable can't (for this problem)? I'd rather go to IEnumerable so that I don't have to require an EntityCollection (sometimes the caller might not have an EntityCollection).
In terms of Northwind ... let's say I want to one or more Products to an existing Order. The Products and Orders have been fetched.
Tk = Order, Ti = Product, Tj = Order Details.
So, for each existing Order <-m:n-> Product, there is one Order Detail record. I want to add a new Order Detail record to link another Product to an Order, thus I need to create a new Order Detail record.
Now that's all very easy to do, however, I don't just have an Order <-m:n-> Product relationship to deal with. I have many Ti <-m:n-> Ti types of relationships. In a particular scenario, Tk will remain constant, but there will be a list of 1 or more Ti to "link" via a new Tj. If the Tj already exists (think, if the Order Detail record already exists), then I don't do anything. If it doesn't I have to make a new Tj.
I another scenario, I will pass in a list of Ti that I no longer want associated with Tk. Think: I want to remove a product from an order.
Ok, so the reason is ... imagine if you were to open up a form for a certain kind of Order ... like an Order with an OrderType of Overnight or something ..., the Order is constant within that form.
Now you display two grids, master detail style. In the first you have a list of all the ProductTypes that are able to be delivered overnight - a ProductType grid. When the user picks a ProductType, the list of all the Products of that type are displayed in the second grid. So there's not just a Product ... there's a BigProduct, SmallProduct, AppleProduct, OrangeProduct, whatever.
A checkbox column is added to the second grid to allow the user to select which products. They may also view currently selected and unselect them as well.
The selected products are iterated through when the user saves, and if a relationship already exists, it's skipped. If not, it's created. Unselected products are also iterated through and existing relationships are removed.
So, I want to be able to use the same code on any scenario that's similar to the one described: Add or remove an m:n relationship, no matter what type of m or n they are, because we do this many places, and over and over again. The code is a giant swicth statement that requires us to check the type of entity and specify the exact collection.
Sorry for the wall of text.