O/R Mapper

Sitter och pillar med min O/R Mapper och har kört fast med relationer. Hur har ni löst många till många relationer och många till en relationer? Behöver lite uppslag...

Ett exempel är användarhantering, har en class Account

public class Account
{
   // properties

   public RoleCollection Roles
   {
      // get/set
   }
}

Några förslag på lösning då Roles och Accounts har en många till många relation?

Jag brukara använda mig av lazyloading. Om jag tar ett enkelt en->många förhållande så blir det så här:

public class Company{
 private long _CompanyIdentifier;
 private EmployeCollection _Employes;

 public long CompanyIdentifier{}
 public EmployeCollection Employes{
  get{
   if(_Employes == null && _CompanyIdentifier != 0)
    _Employes = new EmployeCollection(_CompanyIdentifier);
   return _Employes;
  }
 }
}

Nu laddar jag in alla employes som har tillhör företaget! väldigt enkelt.

Vid många->många förhållande så kan det bli lite mer komplicerat. Allt beror på att du nu har den information du behöver i 2 tabeller istället för 1 som du hade innan. Det enklaste sättet är att i din ORMapper stödjer användandet av SP och kan sätta vilken SP som skall köras, då kan du göra likadant och skicka med vilken SP som skall köras. Typ så här:

public EmployeCollection Employes{
 get{
  if(_Employes == null && _CompanyIdentifier != 0){
   _Employes = new EmployeCollection(_companyIdentifer);
   _Employes.SPToRun = "SP_GetEmployessFromCompanyId";
   _Employes.Load();
  }
  return _Employes;
 }
}

Det andra jobbigare sätter är om du skapar SQLkod i din ORMapper så måste du berätta för din ORMapper att du vill göra en join på tabeller samt vilka kolumner som skall matchas motvarandra, typ något sånt här.

public EmployeCollection Employes{
 get{
  if(_Employes == null && _CompanyIdentifier != 0){
   Join join = new Join();
   join.JoinTable = "tblCompanyEmployee";
   join.JoinOn = "EmployeIdentifier";
   join.JoinWhere = "CompanyIdentifier";
   join.value = _CompanyIdentifier;
   _Employes = new EmployeCollection(join);
   _Employes.Load();
  }
  return _Employes;
 }
}

Jag har med båda varianter, dels så kan min ORMapper använd sig av SP som jag sätter, (dock inte runtime, inte så svårt bara att utveckla Interfacet som alla classer måste ha för att ORMappern skall fungerar) samt att jag kan skicka med ett Join objekt och skapa SQL utifrån det. Det kan finnas behov av båda och därför så bör din ORMapper klara av båda två.

- M

Många till en relationern verkar egentligen inte vara något problem. Lätt att göra som du skriver.

När det gäller många till mångar har jag testat den senare varianten i ett annat utförande som fungerar bra att hämta data, hur gör du när du förändrar/tar bort data som är med i en m till m relation? Angående SP kan det vara ett vettigt steg att ta vid vidareutveckling. I dagsläget är det prioritet att få en bred bas att köra applikationen på. Tyvärr har väl MySQL ännu inte stöd för SP.

När det gäller många till mångar har jag testat den senare varianten i ett annat utförande som fungerar bra att hämta data, hur gör du när du förändrar/tar bort data som är med i en m till m relation?

Förändra och ta bort data är betydligt mer komplicerat, jag brukar ha ett många-många klass alltså en klass för många-många tabellen som jag använder mig av när något skall förändras i den tabellen

Det andra alternativet som faktiskt är smidigare men som kräver mer av din ORMapper (jag har inte orkat implementerat det än) är att du har ett många-många attribute på din employeevariable som berättar vilken tabell som är många till många tabellen vad de olika kolumnerna heter och till vilka variabler de skall matchas. Sedan skall din ORmapper när det görs en save/delete kontroller om ,ånga-många attributet finns och då göra operationerna mot den tabellen och de kolumnerna som finns i som information i attributet.

Det blir även mer jobb för ORMapern eftersom den måste göra det varje gång som du ändrar något i din companyklass även om du inte har ändrat antalet employes så måste den gå igenom alla de employes som du har laddat till ditt företag, och är de inte laddade så måste de laddas först eftersom man inte annars kan lägga till de igen. Inte nog med det, när du väl ta bort en employee så måste det finnas information om att posten också skall tasbort i många-många tabellen, det sista kan man ofta lösa med relationer i databasen, men om man inte kan det så måste den information tillföras till ORMappern så den vet att när den skall ta bort många-många informationen.

Det är som sagt mycket jobb som ORMappern måste göra, därför så har jag inte orkat implementera det än, utan använder en klass för många-många tabellen som jag själv sköter hand om i mina .Save() /.Delete() methoder på de olika objeckten.

- M

Såg att Wilson hade en liknande funktion där man anger relationstyp något som gör hela lösningen lite snyggare tycker jag men verkar komplicerat som du säger. Kör på en klass tillsvidare, får vidare utveckla senare... har lite tidpress.