Kan objekter betale sig?

For småting, hvor du arbejder på egen tid: formentlig ikke.
Store ting, for andres penge, i samarbejde med andre: sikkert.

Hvad i alverden er dette for en diskusion, hvis jeg må spørge?!?!?!

Alt hvad du arbejder med i .NET platformen, mht til app development er da objekt orienteret!

Så ja.... det kan betale sig,- ALTID!

Kommer an på hvad du vil. Så snart at du skal have mere end bare udskrive klokkeslet eller klient-ip så er OO altid mest praktisk.

>>> respak

System.DateTime.Now ligger i et modul i stedet for en klasse og skal derfor ikke instantieres. Det er korrekt!

Men hvordan vil du lave softwaren (applikation arkitekturen) til et ordentligt website, uden brug af klasser?

Til småting behøver man slet ingen overvejelser omkring arkitektur. Det gjorde
man (typisk) heller ikke med ASP.

master_fatman -> har du læst hvad jeg skrev? ;-)

erikjacobsen -> enig (selvom jeg har MEGET lidt erfaring med non-OO)

Ville I så have de objekter liggende i serverens hukommelse (Hvilken måde er lige nu lige meget), eller ville I hente dem i database, oprette objekterne og så vise den side brugeren havde bedt om ved hver request. Hvis man nu f.eks. skulle udskrive en liste over medlemmer/brugere af en eller anden hjemmeside.

Det som jeg havde forestillet mig kunne vinde noget, ville være hvis man kunne opbygge en arkitektur, hvor man kunne gå lidt væk fra den alm. .asp opfattelse (Som jeg betegner som en slags 'Transaction Script')

Håber flere vil deltage i denne "diskussion"... :-)

dna

jeg ville nok hente fra databasen ved hver request... i nogle tilfælde er det nok med kun at hente fra DB ved !IsPostBack.
Du kan næsten ikke undgå at benytte serverens hukommelse, men ellers ligger der jo en hel del data i viewstate.
Ved ikke om det overhovedet gav dig svar på noget???

Hvis man henter dataen ud fra db´en ved hver visning (request), så har jeg nemlig svært ved at se det smarte i at oprette f.eks. medlems-objekter, bare for at vise dem i en liste?

Mine tanker var måske mere hen af at have f.eks. en collection af objekter liggende i ApplikationObjektet - altså have en form for modelkomponent liggende i hukommelsen, og dermed spare nogle (Mange) dbkald. Men, er det en god idé? :D

dna

det smarte ved at kalde DB hver gang er at du er sikker på at du ser de nyeste opdaterede data.
Du kan i teorien godt have dine data liggende som app.obj, men så skal du sørge for at der er datasamtidighed. Det kan godt give problemer med hastighed også.

Men jeg kan ikke se hvorfor du vil oprette medlemsobjekter i en liste...? Hvad er det for en liste og hvorfor?

[Now er en static property i en klasse]

Jeg tror at du skal skelne skarp mellem arkitektur/design og implementation/kodestil.

Du kan:
  - have en writeback cache med data (hurtig, crash mister data, kræver eksklusiv DB adgang)
  - have en writethrough cache med data (hurtig, crash mister ikke data, kræver eksklusiv DB adgang)
  - ikke cache dine data (langsom, crash mister ikke data, kræver ikke eksklusiv DB adgang)

Dit valg bør baseres på kravene til din applikation og ikke bestemmes af
programmerings sproget.

Med lidt større ting er det essentielt at adskille præsentation og
forretnings logik. Ja faktisk vil man helst dele det op i 3 ifølge MVC,
men lad os nøjes med de 2 for klarhedens skyld.

Og allerede her har ASP.NET nogen fordele fremfor ASP.

Med noget større ting begynder den måde koden laves på virkeligt at betyde
noget. Og her er OOP en stor hjælp. Og et par objekter som man kalder
metoder på er altså ikke nok til at kalde det OOP. Vi snakker interfaces,
abstrakte basis klasser, GoF patterns etc..

Og det kan C# og VB.NET i modsætning til VBScript.

For 15 år siden havde jeg som tommelfinger regel at man skulle
over 2000 linier kode for at OOP var bedre end procedural programmering.
Jeg er nok blevet lidt klogere siden. Men det kan stadigvæk ikke betale sig
at sætte det stor OO cirkus igang for at lave HelloWorld.

Vil "lidt klogere" betyde at du øger eller sænker tallet 2000 ?? ;)

Spøg til side.

En tilmelding til en mailingliste: ligemeget, gør som i gammeldags ASP-
En e-forretning: Så skal det være objektorienteret.

Men det er jo lidt sjovt/trist, at de indbyggede <asp:...> tingester i ASP.NET,
der går direkte i databasen ikke i sig selv adskiller præsentation og forretningslogik.
Tværtimod. Personligt synes jeg de bedst egner sig til Q&D-løsninger, og at man
til rigtige web-applikationer skal lave lige så meget arbejde som i alle andre
udviklingsmiljøer.

(Q&D=Quick and dirty)

Takker for alle de gode kommentarer!
I har helt sikkert givet mig noget at tænke over!

Jeg vil prøve at tænke mine krav igennem i forhold til den måde jeg vil implementere det på! Det er kun et fritidsprojekt (Godt nok et stort et), så giver mig god mulighed for at lege med det!

Lader lige spørgsmålet stå åbent lidt endnu, hvis andre skulle have en mening?!

Hvis folk vil have del i points, så skal de lige ligge et svar! - repsak, arne_v og erikjacobsen (Hvis du vil have denne gang *g*)

dna

erik>

Jeg har fået mindre tillid til så firkantede regler. Så lad os sige at
jeg er gået fra 2000 til 500-2500 linier (der er nok en svag nedadgående trend).

De tilsvarende for JSP har fået følgende klamamse i J2EE tutorial fra SUN:

"The JSTL SQL tags for accessing databases listed in Table 14-8 are designed for
quick prototyping and simple applications."

Og et svar

hvis du kunne bruge det til noget såhh :-)

Venter lige på svar fra Hr. Jacobsen!

Ellers tak, jeg samler ikke på point. Og da slet ikke for luftige, ukonkrete råd ;)

Tak for "hjælpen" :D

SDK:

Because Now is a member of a module, rather than of a class, you do not need to create an object on which to access Now.

Men hva.....

Den sætning drejer sig ikke om System.DateTime.Now men om Now i Microsoft.VisualBasic

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vaproNow.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemdatetimeclassnowtopic.asp