Three tier application

1) hvis du syntes at du bliver nødt til at have en lille forbindelse andre steder, så har du design-fejl i din applikation.

2) Du bruger en OR-mapper. Det er et komponent der kan tage dine Businnes objecter og gemme dem i databasen, og igen, hente Business objecter ud fra databasen.

Hvis der skal være nogen mening med lagdelingen af din applikation bliver du nød til at overholde den til punkt og prikke. Selvom det nogen gange kan virke som ekstra arbejde.
F.eks. bliver du nød til at have en metode i DAL som du kan kalde fra business logikken, og som så leverer data, for al data du skal hente ud fra datakilden. Det der gerne skulle være det smarte er at du skal kunne udskifte DAL uden at ændre i business logikken, altså hvis du skifter DAL ud til et der henter fra en anden type database, må business logikken ikke bliver berørt af det.

med risiko for at blive betragtet som en gnaven gammel mand  vil jeg postulere at
du har en 3 tier:
  browser
  web server
  database server
hvor du i dit web server tier har 3 layers:
  præsentation
  forretnings logik
  data tilgang

Det er nærmest en definition på et layer at det kun kan kalde det næste layer
og kun bliver kaldt fra det forrige layer.

Så derfor kalder du i dit presentation layer kode i dit business logic
layer som kalder kode i dit data access layer som tilgår databasen.

Hvis din applikation er meget simpel således at der ikke er nogen
business logic kan du jo overveje at droppe det layer.

Data access layer skal returnerer et eller andet objekt til business logic
layer med data i. Hvilken slags objekt og hvordan data access layer henter
data op fra databasen og over i objektet er der mange forskellige
løsninger på.

Og undskyld mixet af danske og engelske termer.

Tak for uddybningen alle. Nu har jeg lige nogle følge spørgsmål:

burningice-> Hvad er en OR-mapper? Jeg har ledt efter det, men kan ikke umiddelbart finde noget om det.


nheilbuth-> Vil det rent teknisk sige, at man fx har en metode i sit DAL som returnere et dataset, og det skal den kunne gøre ligemeget hvad type db man bruger? Altså således at man ikke behøver skifte business logikken ud, hvis denne er beregnet til at arbejde med et dataset?


arne_v-> Har du nogen eksempler på de forskellige løsninger (en sproglig forklaring er også fint)
Ps. det gør ikke noget

En OR mapper er noget som kan mappe mellem objekter og rækker i tabeller i relations
databaser.

De findes i mange afskygninger.

Men lad mig give et stiliseret eksempel.

Vi har en klasse:

public class T1
{
    public int f1;
    public string f2;
}

så har vi en tabel i database:

t1
--
f1 integer pk
f2 varchar(50)

så laver vi en mapning:

<arnesmapper>
  <class name="t1" table="t1">
      <field name="f1" column="f1"/>
      <field name="f2" column="f2"/>
  </class>
</arnemapper>

Så kan man bruge:

T1 o = arnemapperinstans.Load(123);
o.f2 = "ABC";
arnemapperinstans.Save(o);

Der findes en million varianter, men ideen må fremgå af ovenstående.

Det må være et absolut krav til et godt data access layer at der ikke skal ændres
i business logic layer eller presentation layer hvis du skifter database - i nogle
tilfælde vil du endda kunne skrive dit data access layer så det ikke skal ændres

data fra database til objekter kan gøres med:

* data adapter og data set

* data reader og array/ArrayList af objekter

* O/R mapper og array/ArrayList af objekter

og sikkert mange flere

ok, så har jeg været inde på noget af det rigtige i mine overvejelser, jeg synes bare det så lidt mærkeligt ud, især det med at kalde hive data ud fra en database (gennem datalaget vel at mærke) i selve klasserne i business logikken.
Jeg har nemlig studeret et par ASP.NET sample apps for at se noget om "best practice" osv. i større applikationer, og her så jeg mange forskellige løsninger, men ingen have en business logik der brugte et datalag. Der var enten kun et datalag, eller ingen flere-lags struktur i dem, derfor forvirringen.

Nu tror jeg jeg er mere rustet til større opgaver, og vil derfor gerne give jer nogle point :)

Smider i et svar? I har i virkeligheden alle været lige hjælpsomme!

problemet med 3 lag er at det kun giver mening i realistiske eksempler - i hello
world er der ikke meget behov for det - og de færreste artikler bøger indeholder
5000+ linier kode

og svar

nej det har du selvfølgelig ret i, men ASP.NET StarterKit Portal sample applikationen er da lidt stor. Der har de kun et datalag, og benytter det direkte i codebehind til .aspx siderne...

Vil i andre ikke også lige svare, så vi kan få lukket?

der er knas i Ekspertens email system så de får ikke email om at der
er aktivitet så det kan godt vare lidt inden de kigger forbi

iøvrigt synes jeg ikke nødvendigvis at .aspx.cs hører hjemme i presentation layer

i nogen tilfælde kan man argumentere for at det er business logic layer

eller hvis man skifter til en 4 layer model (presentation, controller,
business logic, data access) så kan man kalde det for controller
layer

den sidste synsvinkel er jeg blevet meget glad for på det sidste

hvad vil du da have i dit presentation layer hvis det ikke skal være .aspx.cs sider?

.aspx

hmm, ok.

jeg har prøvet at arbejde lidt videre, og har nu fået et mere konkret problem:

jeg har en galleri-klasse til et billedgalleri, med en constructor der tager 0 argumenter. Derudover har jeg en der tager 1 argument (int id) som skal repræsentere den primære nøgle i galleri-tabellen i databasen, til når man fx vælger /galleri/?id=4. Hvad kan jeg så gøre mht. mit data layer, der sørger for at proppe noget data i de andre properties i klassen som fx overskrift, dato osv? Jeg tænkte på noget med en del der kan hente enkelte kolonner ud som strenge, men så skal jeg jo i princippet lave en metode til hver klasse i business laget!

Hvad vil du/i foreslå?

Nå, nu gider jeg ikke vente mere.. Her er dine points arne_v

jeg vil sige at din galleri-klasse er en del af dit data access layer, og den vil se nogenlunde sådan her ud:

public class ImageGallery {
  private string name;
  public string Name {
      get { return name; } 
  }

  public void ImageGallery(int id) {
      string sql = "SELECT name FROM tblImageGallery WHERE id = "+ id;

      DataStore ds = new DataStore();
      IDataReader reader = ds.ExecuteReader(sql);
      reader.Read();

      this.name = reader.GetString(0);

      reader.Close()
  }
}

På den måde kan du i din Business Logik Layer f.eks. gøre følgende:

ImageGallery gallery = new ImageGallery(int.Parse(Request.Querystring("id"));
lblName.Text = gallery.Name;