Great post by the way, I love it when on the very first post the problem at hand is clearly laid out so we don't spend the first few posts trying to get at the actual problem, so thanx for that. Since AssignPrimaryKeys and RemovePrimaryKeys are non-trivial functions locking around the entire FindByPrimaryKey isn't optimal, I agree on that for sure.
Here's what I'm thinking. Suppose we add a property called "Cache" or some such flag that you set to true. That basically calls AssignByPrimaryKeys() and from then on FindByPrimaryKey checks the flag and doesn't call those support routines. However, I would then also like to make Filter / Sort be able to work against the same collection, and make sure that enumeration is thread safe. I think this is a great idea, making our collections thread safe, is something we should do. However, it probably wont make this release.
This might help you, we have a method in the collection that does this:
Code:
public static implicit operator List(EmployeeCollection coll)
{
List list = new List();
foreach (Employee emp in coll)
{
list.Add(emp);
}
return list;
}
Here's a method that we can add in the next release for sure.
Code:
public static implicit operator Dictionary<int, Employee>(EmployeeCollection coll)
{
Dictionary<int, Employee> dictionary = new Dictionary<int, Employee>();
foreach (Employee emp in coll)
{
dictionary[emp.EmployeeID.Value] = emp;
}
return dictionary;
}
But, in reality we couldn't make it as simple as above, the problem is composite primary keys, we need to be all things to all people ... What are you thoughts on all this?
[Modified]
To use the above code you would do this:
Code:
EmployeeCollection coll = new EmployeeCollection();
coll.LoadAll();
Dictionary<int, Employee> dictionary = coll;
EntitySpaces |
Twitter |
BLOG | Please honor our Software License