Hi, yesterday we where discussing about saving a many to many relation. To keep the UI and BL seperated, we want to save the M:M in the BL (we use Selfservicing and use HnD as an example). Now we have this situation where we have to save a M:M relationship. In the UI we have a checkboxlist and with every checkbox item comes 2 textboxes. You could see this as an entity.

A user can check multiple checkbox, if he does, he has to fill in the textboxes belonging to this item.

now we want to save and are wondering if we should create a collection in the codebehind of the UI page or we should collect the data, store it in a multi dimensional array and send this array as a parameter to a function in the BL and then save.

Is there any best practice about this issues?

An other point is that these items have to have a FK, but this FK is not created at the moment of saving. Actually, on save, because of dependency, this FK will set because the parent item is inserted first. Am I correct?

Hope anybody can advice.

You may directly use Entities in your UI code behind. The following is an example from the manual about saving entities with m:n relation:

DepartmentEmployees newDepEmp = new DepartmentEmployees();
newDepEmp.Employee = employee;
newDepEmp.Department = department;
// the 3 entities are now linked. We can now save recursively any of the three (doesn't matter) 
// to save the relation in the database.
employee.Save(true);

Upon Saving, FK-PK syncronization should be taken care of automatically.

Hi Walaa, thanks for the reply. We will discuss this with my colleagues.

Well we are discussing it right now, and my colleague assumes that it should also be possible to just creating instances of two entities. In this case of employee and department Because the DAL has knowledge of the relation between these two tables a third entity, in your example the DepEmp entity would not be needed.

Is this assumption correct. He is will test this today, but I'm still curious.

my colleague assumes that it should also be possible to just creating instances of two entities. In this case of employee and department Because the DAL has knowledge of the relation between these two tables a third entity, in your example the DepEmp entity would not be needed.

That's not always the case when you are Inserting New entities and inserting the row which define the m:n relation between them in the middle table. As sometimes the middle table may contain other fields that are specific to the relation other than the 2 FKs of both sides of the relation. That's why the middle Entity needs to be defined and saved too.

To elaborate a bit more on what Walaa said: DeptEmp might be an entity with just a PK with FK fields. So in that particular case it can be hidden.

Then you write your code as if it's hidden and all is well.

Then something changes, you need a 'startdate' on that entity, which isn't part of the PK. Suddenly it becomes a non-hidden entity.

Your code then starts to fall apart as you assume it's hidden, while it's not. That's why these relations are never hidden, so nothing is obscure and you won't run into surprises afterwards when something changes.

Thanks guys, this will do.

Laters