A static method to get entity collections?

Posts   
 
    
Posts: 22
Joined: 20-Sep-2006
# Posted on: 10-Oct-2006 17:09:22   

I have a class that I call to keep fetches deletes ect. out of the BL and just use simple static calls to invoke these methods. Much like this


   public static bool Fetch(IEntity2 _entity)
        {
            bool returnVal;
            using (DataAccessAdapter _adapter = new DataAccessAdapter())
            {
                returnVal = _adapter.FetchEntity(_entity);
            }
            return returnVal;
            
        }

I would like to do something similar with Entity Collections, however I'm unsure if this is really practical since the collection should have at least one overload to use a relation filter

I could do something like this


   public static bool FetchCollection(IEntityCollection2 _collection, IEntity2 _caller)
        {
            bool returnVal;
                using (DataAccessAdapter _adapter = new DataAccessAdapter())
                {
                    returnVal = _adapter.FetchEntityCollection(_collection, _caller.);
                }
           return returnVal;
        }

Where _collection is the collection to be returned and _caller is the entity to be related. However I'm unsure how I would know the Predicate (hopefully I'm using the right term disappointed ) for the _caller entity would be something like _caller.GetRelationInfoxx where xx = the related table.

Anyone have any thoughts on this? Very new to LLBL so I appreciate any help I can get.

Thanks, Justin

bclubb
User
Posts: 934
Joined: 12-Feb-2004
# Posted on: 11-Oct-2006 02:58:08   

We handle this by basically providing a search service that takes in the same parameters as the adapter to fetch an entity. So we have methods such as

public static EntityCollection SearchEntityCollection(IEntityFactory2 factory, IRelationPredicateBucket predicateBucket, IPrefetchPath2 prefetchPath, ISortExpression sortExpression, int pageNumber, int pageSize)
Posts: 22
Joined: 20-Sep-2006
# Posted on: 11-Oct-2006 16:34:43   

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 simple_smile )

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

simple_smile

Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 11-Oct-2006 16:54:17   

IMHO: A better DB Design would be, to create a table say "Person". From which Vendors, Drivers & Customers inherits (1:1 relation). i.e. Vendors PK is also a FK to the Person PK. Person PK can be an Identity column, but the subTypes, can't have an Identity column since they are already referencing the common Idenity created in the Main-Type (Person)

Put all the common fields in the Person table.

Define relations between other related entities (Contact) and the Main-Type (Person).

Read the following sections in the LLBLGen Pro manual: Concepts -> Entity inheritance and relational models Designer -> Inheritance mapping