bclubb wrote:
We handle this by basically providing a search service that takes in the same parameters as the adapter to fetch an entity.
Not sure that this really fits my situation (I also don't know any better so please let me know if I'm wrong )
My Problem is two fold, this may warrant another thread but for the moment I'll leave it here.
Problem 1.)
I would like to be able to create a static class to create entity collections and return it to the caller. I'll only know the caller and whatever related predicate information at runtime not at design time.
Problem 2.)
In my current database I have an Enity type Vendor, I also have a multiple Contacts for the entity type of Vendor, contacts are ALWAYS a child never a root, but they are also availble to differnt entity types, drivers, customers, ect.
In the database we have now there is a table called Entities (I absolutely hate this) that relate Vendors, Drivers, Customers ect to common entity types (not just Contacts there are others). Since Vendors, Drivers, Customers are using an @@Identity there can be overlap this is the reason for the Entitiy table (according to my DBA). So common objects like contacts are related to their parent entity (like vendor) through the entity table.
So my delema for my contacts class is how do I get the relationship information, I can't do it at design time because at design time I have no idea who the caller is.
If anyone has any insight into this i would appreciate any advice. Also if someone out there has a better DB design for this sort of scenario, I would be happy to take it to my DBA because this Entity table is really killing me.
TIA,
Justin