jspanocsi wrote:
hello, I've been evaluating your product for a couple weeks now and it's great. i only have one area left to figure out a good solution for.
Let's say I have a db with 3 tables
User
Department
UserDepartment
the user can have several departments.
The user departent table just has 2 fields the userpk and the departmentpk.
Now take a standard winform app like your northwind demo. I have a grid that lists all users and textboxes that populate with standard databinding when you click a row in the grid. You make changes to the text boxes and the grid updates etc. The grids are all readonly.
I then have another grid on the form that shows the departments that the user is in. This works the same way. You pick a row in the grid and a combo box updates to show that department. you can change the combo to change the department and I have an add new department button that works.
The problem I have is that I can make that work by binding the user.userdepartment collection to the 2nd grid, but get "ugly" data displayed. IE the keys instead of a userfriendly name like the department name. I created a typed list and bound the grid to that and it works great for the names, but now I can't update it.
What's a good way to handle this situation?
As it is an m:n relation, you can do two things: bind User.Departments (which is the m:n relation, but this relation is read-only) or use the following approach:
When you click on a user and you fill the textboxes, you can read a DepartmentCollection (or if you're using Adapter, EntityCollection) based on the user, using a filter via UserDepartment.
When the user is done editing and clicks OK to save the User data, you first save the User, then delete all user's UserDepartment objects from the db directly, then add new UserDepartment objects for every Department the user is in. This is the easiest.
The m:n relation is read-only because the intermediate entity is not made hidden. This is done to make teh code consistent: some intermediate entities aren't hidable because they contain non-PK fields (OrderDetail in Order -m:n- Product for example
).
Excellent product!