Jag har en community site där jag självklart har ett objekt som heter user. Ibland vill jag ha ett userobjekt som bara innehåller UserID och Nick. Ibland vill jag ha ett user objekt som innehåller massor av data + collections med t.ex "Personens kontakter" osv osv.

Nån som har haft ett liknande problem. Jag vill ju inte hämta hela user objeketet bara för man t.ex vill kolla om personen är online eller inte t.ex.

Självklart går det lösa på massa olika sätt men nån kanske har nåt konkret tips eller nån "pattern" som är bra att använda i såna här situationer? Det är jobbigt att bara objekt orienterad i en stateless värld ibland :)

Att kontrollera om personen är online eller inte kan du ju t.ex. göra med en delad metod så behöver du inte instansiera något userobjekt.

Angående relaterar data (listor) så kan de ju med fördel laddas vid behov. Exempel:
<code>
Private m_List_X as collection
Public readonly property List_X as collection
Get
if m_List_X is nothing then
m_List_X = new Collection
'Ladda listan med information här
End If
return m_List_X
End Get
End property
</code>
Om du följer dessa två borde du kunna minska objektens storlek och antal databasanrop ganska avsevärt.

Mvh
Peter

Returnera bara det du behöver, använd arv för att få till det

<code>
public class User
{
public User()
{
}

private int _IdUser;
private string _Name;

public int IdUser
{
get
{
return _IdUser;
}
set
{
_IdUser = value;
}
}

public string Name
{
get
{
return _Name;
}
set
{
_Name = value;
}
}
}


</code>


<code>
public class FullUser : User
{
public FullUser()
{
}

private bool _online;
private string _Other;

public bool Online
{
get
{
return _online;
}
set
{
_online = value;
}
}

public string Other
{
get
{
return _other;
}
set
{
_Other = value;
}
}
}

</code>

Vill du kolla vilka som är online och bara få ut användarID och namn så skapa bara objekt av typen User, vill du få fullständig inforamtion så använder du FullUser. Sedan går det ju som sagt att göra på olika sätt, tex dessa två scenarion:
1. Man visar vilka som är online med User i lista, vill man se mer info om en användare så anropar man en funktion som returnerar ett FullUser för just den användaren och utifrån det visar man info.
2. Man visar vilka som är online med FullUser i lista, vill man se mer info om en användare så plockar man bara ut infon från valt objekt.

I fall 1 kommer man att läsa upp lite data initialt och sedan bara hämta data när det behövs medans man i fall 2 kommer att hämta mycket data på en gång. Men som sagt, finns många sätt att göra det på...

Mm.. Det är ungefär i den här stilen jag har det idag.

Sen antar jag att det väl inte direkt är nån dödsynd att t.ex lämna vissa attribut tomma ibland. Jag menar t.ex om jag har en storedprocedure som returnerar namn, äronline, userid och en annan som returnerar bara namn, userid .. så får man väl kasta nån exception eller nåt om man försöker anropa äronline. Man vill ju inte returnera massa onödig data från SQL servern bara för att fylla upp objektet på rätt sätt .. För man kan ju inte ha ett objekt för varje kombination av Stored Procedure man har ..

Men tack iallafall. Ville bara stämma av lite med folk så man inte missat nån grym pattern eller dylikt som man brukar använda i såna här sammanhang ..

Om du har egna objekt så brukar man ju normalt ormappa
och de flesta ormappers stödjer lazyload som gör att du kan välja vilka fält som ska fyllas när du läser upp ditt objekt...

men istället för att kräkas ett exception när du anropar en propp som inte blev fylld så kommer den att läsa den proppen från db och ladda den on demand så att säga..

även om du inte använder en färdig ormapper så kan du stödja lazyload själv ganska lätt:

public int SomeProp
{
      get
      {
           EnsureLoaded("SomeProp"); //<- tex en metod som anropas först i get delen 
           return this.someProp;
      }
      set
      {
          this.someProp = value;
          FlagAsLoaded("SomeProp"); //<- och något som flaggar att proppen fått ett värde
      }
}

<b>Mm.. Det är ungefär i den här stilen jag har det idag. </b>

Men då har du väl inga problem? Vad jag menar är att man särskiljer objekten och bara returnerar den objettypen som behövs, för listor mm returnreas enbart User, för mer detaljerad info returneras FullUser som ärver vissa attribut från User.

Problemet är ju att man har kanske 6-7 olika scenarion med olika mycket data om usern. Men som sagt man får ju göra en avvägning mellan att ha lite extra perameterar på några av objekten och göra nån form av "arvs hierarki".

Tack för svaren. Känner att jag har lite mer koll nu.