Forskel på business objekter og code behinds?

Code nehind kan vel inkludere business logic.

Men business objects er vel objects med business data ?

codebehind er logikken for en aspx/ascx-side. Businness logic er logic for selve foretningsgangen.

Men er de nødvendigvis gensidigt udelukkende ?

så at man ikke kan have business-logic i sin codebind og omvendt?

Medmindre man gør action konfigurerbar, så ligger der vel noget
business logic i code behind.

Hvis codenehind kalder data direkte : al business logic

Hvis codebehind kalder metoder i nogle business objects : en smule business logic

Hvis codebehind kalde udfra konfiguratiosn filer : ingen business logic

en smule?! det var da en lidt udefiner-bar størrelse.

Jeg vil da mene, at hvis man har en codebehind, hvor det eneste den gør er at oprette et NewsArticle-object (Business Object) og binde dens properties til labels på aspx-siden, så har man klart del territorierne op, og der er ikke noget Businness Logic i sin codebehind.

Du havde jo sikert også undret dig hvis jeg havde sagt 8.37%.

:-)

Hvis man bruger en konkret klasse og kalder en metode i den som
gør noget bestemt forretnings orienteret, så vil jeg også kalde
det kaldende kode fragment for en del af business logic.

I modsætning til at have et interface eller en abstrakt klasse
og kalde en generisk process/execute metode.

Men det er mere terminologi end det er arkitektur.

For at vende tilbage til det oprindelige spørgsmål så er vi nok enige om at:
  - business objects er noget som opbevarer business data og udfører forskellige
    forretnings mæssige opetaioner på disse
  - code behind er kode som står for logikken i præsentationen

Vi har så lidt forskellig vurdering af om den kode i code behind der
kalder business objects er en del af busines slogic eller ej.

Jeg har min mening.

Men jeg er ikke ufejlbarlig. Og jeg er ikke engang kyndig udi
standard ASP.NET terminologi.

;) ja... for jeg ville mene at det var 11.23 % :P

Tja... tjoo... vil dog sige at så længe man inkapsulerer (det kan man sige det ? :)) selve logikken i en klasse for sig, så roder man ikke med business-logikken, bare fordi at man gør brug af en BO-klasse. Lige som at jeg heller ikke arbejder med database bare fordi at den BO-klasse jeg bruger gør brug af en database for at loade/gemme data.

Men det er nok bare et spørgsmål om ord, for det lyder som om vi mener det samme :) Spændende hvad snepnet har af meninger omkring dette ;)

han er helt oppe 14.57 % :oD

(jeg smider nok lige et par ord lidt senere... men jeg skal lige ordne nogle småting :o)

Det er ikke det at code behind kalder business objects.

Det er det at code behind indeholder logik som:
  - ud fra fra user action beslutter hvilke business objects der skal bruges
    og hvilke metoder der skal kaldes
  - beslutter hvilken side der skal vises bagefter
som gør at jeg mener at der er business logic i code behind (i det scenarie).

Kender i Struts ?

I Struts submittes en form til et logisk navn, i en XML konfigurations fil
bestemmes så hvilken klasse der skal processe, den klasse returnerer så
et logisk navn og samme XML konfigurations fil bestemmer hvilken side
der skal vises bagefter.

Kan godt være lidt bøvlet at arbejde med. Men de 2 pinde nævnt ovenfor
er flyttet ud i en selvstændig konfigurations fil. Og giver dermed en
meget løs kobling mellem UI og business logic.

hej med jer :o)

jeg lavede et lille eksempel igår, som jeg ikke fik postet, men jeg tror egentlig vi er meget enige... i kan lige se eksemplet :

hvis man snakker arkitektur, synes jeg der er rigtig mange gråzoner i dette område, men i kan lige få lidt strøtanker.

sådan en som denne her :
(bare opfundet til lejligheden som lidt af blanding af det i har skrevet) :

---
IActionHandler ActionHandler
{
  get
  {
    if(Settings.UseActionHandler)
        return Factory.CreateActionHandler();
    return null;
  }
}

void tb_Changed(object sender, EventArgs e)
{
  if(ActionHandler != null)
  {
    int val = int.Parse(((TextBox)sender)Text);
    ActionHandler.Handle(val, ActionType.Validate);
  }
}
---

hvad er det ?

det er jo sådan set bare et kald til en handler som muligvis er sat op, og som gør et eller andet (måske også afhængigt af en konfiguration), men på den anden side angiver man selv hvad det er for en type action man forventer der skal udføres...

den forventede aktion bunder vel i en sikring af at et en forretningsregel bliver overholdt, og man kender den ikke, men ved det er den man er ude efter.

foventeligt vil der jo nok være et eller andet i bemeldte handler som kunne finde på at gøre et eller andet...
måske endda en :

if(actionType == ActionType.Validate)
{
  if(val > 10 mv...)
  <-- ResultType.CriticalError / ResultType.OK / ResultType.Warning
}

hvor jeg vil mene at der er tale om en regelimplementering :
hvis værdien er højere end ditten - er det en resultattype datten.

men i den oprindelige handler sker der jo også noget... det bliver til :

ResultType result = ActionHandler.Handle(val, ActionType.Validate);

switch(result)
{
  case ResultType.CriticalError :
    // farv feltet rødt
    IsValid = false;
  case ...
  // gult blåt sort lilla brunt hest fisk økse salathoved og hvad ved jeg...
}

jeg tror et projekt hvor man kan tillade sig at sige at der ikke ligger nogen tolkning af resultater, eller stillingtagen til nøjagtig hvilken forretningslogik der skal kaldes er meget sjældent set, og man kan jo kalde det alt muligt der vil give rimelig mening, som "præsentationslogik", "forretningsmæssig sikring af UI", "actionengine" og hvad ved jeg.

man kan nok argumentere for at ovenstående er et halvgjort (og tåbeligt) forsøg på at lave en generisk implementering af noget der burde have været mere konkret, men det skal bare ses som en illustration.
(men sådan bliver det jo gerne de første mange gange alligevel ;o)

Men..... jeg tror at min pointe er - måske især illustreret ved denne :
switch(result)
{
  case ResultType.CriticalError :
    // farv feltet rødt
    IsValid = false; !!! det her har betydning for hvad der sker i præsentationen.

at kunder i højere og højere grad forventer at der i en given frontend støttes meget kraftigt op omkring deres "forretnings-regler" -> at jeg synes det er meget rimeligt at sige at ens præsentationslag er bekendt med, og tager højde for disse.

suk... det var mange omveje til et sidste lille eksempel (som gerne skulle være mere klart) :

someButton_Click(object sender, EventArgs e)
{
  if(someRules.ValidateText(someTextBox.Text))
    someOtherButton.Visible = true;

ovenstående skulle gerne vise en ganske almindelig måde at trække på sine regler (i det her tilfælde en valideringsregel), men jeg er sikker på at kunden på et tidspunkt har fortalt, at de har en "regel" om, at en bruger ikke må kunne sådan, hvis ikke noget andet er opfyldt - og den regel er i eksemplet 100% løst i code-behind til en given form - uden for et dedikeret forretningsobjekt.

det er sansynligvis muligt, at sikre at alle kundes regler er pakket ind i nogle forretningsobjekter, som ligger i et lag for sig selv - uafhængigt af en frontend, men jeg tror at der er meget få kunder der er interesseret i at betale for det.

desuden tror jeg at vi alle sammen gør det i større eller mindre omfang - selvom vi har et dedikeret regellag - og jeg tror at det i mange situationer gør, at man for afleveret noget som kunden er glad for - ikke mindst til tiden :o)

man kan selvfølgelig vælge at kalde det et eller andet ord man ikke kan finde i bøgerne, og på den måde sikre at man kan fortælle at ens opbygning lever op til diverse guidelines mv, men i bund og grund ændrer det ikke på, at man sansynligvis har masser af regler uden for sine forretnignsklasser.

i praksis tror jeg ikke den "rene lagmodel" eksisterer andre steder end på papiret - og jeg har set mange eksempler på at der bruges en masse krudt på at gøre tingene på bestemte måder for at overholde guidelines, som i sidste ende alligevel komprommitteres diverse steder i applikationen.

jeg synes helt klart at der er store gevinster ved at følge intentionerne, men som med alt andet skal det gøres inden for rimelighedens grænser.

Så et frit filmcitat :
Pirates of the Caribbean 2003 - om "The Pirates Code" (håber i har set den :oD) :

(den yndige prinsesse) "You must put me to shore !"
(den klamme skurk) "First - putting you to shore was not part of our negotiation, so i must do nothing. secondly - your must be a pirate for the pirates code to count - and your not. and thirdly - the code is more what you would call guidelines, than actual rules".

Såhh....
1) Har kunden ikke specifikt aftalt en bestemt arkitektur - har man frie hænder.
2) Hvis man ikke er arkitekt tæller reglerne alligevel ikke.
3) Det er overhovedet ikke regler - men gode idéer.

intet af ovenstående ændrer dog ved - at jeg synes "sådan nogle som os" har en forpligtigelse til at arbejde med området, gøre vores erfaringer og (forhåbentlig) vende dem til udbytte for alle på det næste vi laver.

desuden er det under alle omstændigheder "sådan nogle som os" der gør, at der er nogle der sidder om 10 år og river sig i håret for at overholde de arkitektoniske "regler" som det vi har lavet har afstedkommet ;o)

håber ikke det var alt for tåget (men som jeg startede med at sige, synes jeg selv at der er mange gråzoner i området).

tak fordi i er med til at gøre det til en fed branche !

- "In this job - it should be fun to be serious !" (Jeppe Rørbæk 2004)

/snep

når man ligefrem bliver inviteret - tak cyberfessor - må man jo pippe lidt med :o)
mvh

Jeg siger tak for de gode indlæg - alle der smider et svar kan få sin del af de 30 point ;-)

svar

og et til

svar

takker