--- title: "OO i webbvärlden" type: "forum-thread" url: "https://www.webforum.nu/amne/dotnet/167879-oo-i-webbvärlden" topic: ".NET" topic_url: "https://www.webforum.nu/amne/dotnet" author: "doggelito" published: "2008-01-08T12:26:13.000Z" updated: "2008-01-08T15:45:03.000Z" replies: 18 views: 607 page: 1 pages: 1 language: "sv-SE" site: "webForum — webforum.nu" rights: "Upphovsrätten till varje inlägg tillhör dess författare." attribution: "Citera som: webForum, https://www.webforum.nu/amne/dotnet/167879-oo-i-webbvärlden" --- # OO i webbvärlden ## #1 — doggelito, 2008-01-08T12:26Z Jag tycker det är fantastiskt roligt att lära sig nya saker och OO programmering är en sådan sak. Det är ju bra mycket roligare att koda .net mot att scripta gammal asp! :) Men en sak jag inte riktigt greppat dock är när man ska/bör använda all den teknik som finns tillgänglig. Eftersom jag till 95% jobbar mot webben så undrar jag om någon vänlig själ kan ge exempel på när ni använt OO. Alltså ni behöver inte visa någon kod utan berätta istället vad och varför ni valt en viss teknik. Hur kan man implementera OO när man bygger ex. ett forum, en webbutik, en nyhetsmodul osv. Mao, vanliga webbmoduler! (och snälla, inga påhittade exempel som det klassiska fordonsexemplet där man har en basklass som sedan ett tåg eller en bil ärver!) Kan någon upplysa om detta så man liksom kommer in i tänket så blir jag väldigt tacksam! :) Permalänk: https://www.webforum.nu/p/167879 ## #2 — freguz, 2008-01-08T12:35Z Vad är OO? :OO Jag bygger webb dagarna i ända, använder i jobbet typ bara EPiServer som är ett CM system med massa klasser, PageData objektet ärver från PageBase osv, men det jag gör är ju aspx/ascx med lite codebehind samt sedan ett gäng klasser som är de objekt jag vill använda, kan ju radda några på skoj: XmlImport, RssManager, CacheMaster, Product, Review, Settings, XmlBase (basklass till alla xml klasser), ReviewImport osv och förstås alltid en Util klass med statiska metoder (så trådsäkra som möjligt). Men jag vet inte om jag jobbar enligt OO eller inte faktiskt, eller om jag ens vet vad det är... jag tänker nog mer "lösningsorienterat" än "objektorienterat" :D Permalänk: https://www.webforum.nu/p/2068793 ## #3 — Compusa, 2008-01-08T12:47Z Objektorienterad analys och design (OOAD) är grundstenen. En bra början finns här: Kolla lite sedan på referenserna i artikeln. Börja googla på nyckel-ord/termer och köp [en vettig bok](http://www.amazon.com/s/ref=nb_ss_b/103-5842262-9844630?url=search-alias%3Dstripbooks&field-keywords=ooad&x=0&y=0). Jag har [denna](http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062/ref=pd_bbs_2?ie=UTF8&s=books&qid=1199796570&sr=1-2) :) Permalänk: https://www.webforum.nu/p/2068797 ## #4 — doggelito, 2008-01-08T12:52Z Det är alltid svårt att förklara om man inte vet exakt vad den som frågar är ute efter, jag vet. :) För att göra det lite enklare (kanske), om vi tar webForum som exempel. Ett vanligt forum! (fast lite bättre än andra) webForum har kategorier, trådar, inlägg, användare, kalender, inställningar, mailfunktioner, meddelandefunktioner, sök m.m. Vilken klass skulle med fördel ärva en annan? Permalänk: https://www.webforum.nu/p/2068799 ## #5 — nitro2k01, 2008-01-08T13:38Z Jag har lite samma problem med OO på webben, och anledningen är att objekten inte (Om jag inte har missförstått) är persistenta, utan måste återskapas för varje instans av en sida. det gör, enligt mig, att lite av fördelarna med OO försvinner. Permalänk: https://www.webforum.nu/p/2068803 ## #6 — Gladh, 2008-01-08T14:13Z > **Frequz skrev:** > > Men jag vet inte om jag jobbar enligt OO eller inte faktiskt, eller om jag ens vet vad det är... Så fort du sätter igång VisualStudio så jobbar du OO även om det kanske inte känns så för dig, du kan faktiskt inte köra en .NET program utan att ha en klass i botten. Därmed jobbar du ObjektOrienterat. Jag är övertygad att din EPIServer också betstår av objekt som du instansierar och använder dig av, lika så att funktioner i .NET. SqlConnection är ett objekt, SqlDataReader är ett objekt, string är ett objekt, osv osv. Så visst jobbar du objektorienterar, även om just den kod du skapar kanske inte är så OO som du/man/vi önskar... \- M Permalänk: https://www.webforum.nu/p/2068808 ## #7 — nitro2k01, 2008-01-08T14:18Z > **Gladh skrev:** > > Så fort du sätter igång VisualStudio så jobbar du OO även om det kanske inte känns så för dig, du kan faktiskt inte köra en .NET program utan att ha en klass i botten. Därmed jobbar du ObjektOrienterat. > > Så visst jobbar du objektorienterar, även om just den kod du skapar kanske inte är så OO som du/man/vi önskar... Det där är lite av en tolkningsfråga. Även om språket man jobbar med är OO betyder inte det att koden man skriver är OO. Man kan mycket väl bara skapa en konstruktor och lägga all kod där à spagettikodning. Även om man använder ett objektorienterat språk betyder det inte att man har följt paradigmen OO för det. Permalänk: https://www.webforum.nu/p/2068811 ## #8 — Gladh, 2008-01-08T14:31Z > **doggelito skrev:** > > webForum har kategorier, trådar, inlägg, användare, kalender, inställningar, mailfunktioner, meddelandefunktioner, sök m.m. > Vilken klass skulle med fördel ärva en annan? Av just de exempel som du har gett här, har jag svårt att se att någon skulle ärva någon annan i ditt exempel. Jag tror du stirrar dig blind på felsaker, ett objekt är som ett substantiv, om du kan sätta en/ett/flera framför saken så kan du även göra det till ett objekt. När man sedan kommit så långt så kan man börja tita på vilka egenskaper ett objekt skall ha, ta en artikel i en webshop. Den skall ha ett pris, den skall ha ett artikelnummer och ett namn, den kanske skall tillhöra en kategori, och därmed har vi fått en relation mellan detta objekt och vårt kategoriobjekt. Den kanske skall ha en bild. Jag har dock svårt att se att den borde ärva från något, eller att något skall ärva från denna artikel. Däremot så kanske du skapar 2 olika webbutiker som mycket påminner om varandar, bara att i den ena webbutiken så skall artikeln ha med en egenskap som heter 'Beskrivning' som inte finns i den andra webbutiken. Här kan man nu börja ana vinsten med ärv, här kommer en kort förklaring. webbutik1. ``` public class Product{ public string Name; public int Price; public string Number; } ``` Till denna butik har vi byggt ett affärslager som kan ta alla produkter och lägga samman summan av dessa och få tillbaka totalen. ``` public int TotalPrice(List products) { ... return totPrice; } ``` Om vi nu börjar bygga den andra webbutiken och där har vår produkt som även skall ha en egenskap som heter beskrivning. ``` public class Product{ public string Name; public int Price; public string Number; public string Description; } ``` Vi vill även här kunna lägga ihop alla produkter och få fram ett totalpris. Vi kan skapa ett nytt affärslager där vi skriver en ny TotPrice() metod, eftersom den endast tar emot en **Product** från webbutik1, så kommer vår **Product** från webbutik2 inte fungera om vi försöker skicka in en lista med sådan till metoden, eftersom dessa 2 ligger i olika assembliers. Den man kan göra här nu för att ÅTERVINNA vår TotPrice() metod är att vi skapar en bas produkt klass ``` public class BaseProduct{ public string Name; public int Price; public string Number; } ``` och även en ny Product för respektive webbutik som ärver från vår BaseProduct ``` public class ProductForShop1 : BaseProduct { } ``` ``` public class ProductForShop2 : BaseProduct { public string Description; } ``` Vi kan nu skapa ETT affärslager som tar emot basprodukten och räknar fram totalpricet för alla produkter. ``` public int TotPrice(List products) { .... return totPrice; } ``` Här har vi alltså använt OO för att kunna minimerar koden som vi skriver för att kunna leverera 2 webbutiker med olika krav på hur produkten behöver se ut. Nu kanske just TotPrice() var ett dåligt exempel, men du kan applicera det på det mesta i din webbutik. För varje order så kommer du ha en orderrad, denna orderrad skall bestå av din produktnummer, antal, pris, mm.. Här kan vi också skriva EN affärslogik metod för att hanterar detta även om vi har 10 olika produkter, så länge de alla ärver från BaseProdukt, och BaseProdukt innehåller den information som vi behöver för att fylla OrderRaden. \- M Permalänk: https://www.webforum.nu/p/2068812 ## #9 — Gladh, 2008-01-08T14:38Z > **nitro2k01 skrev:** > > Man kan mycket väl bara skapa en konstruktor och lägga all kod där à spagettikodning. Även om man använder ett objektorienterat språk betyder det inte att man har följt paradigmen OO för det. Det är OO hur du än vänder och vrider på det, att du sedan skriver dålig OO kod är en annan sak. Du har ju tappat styrkan och funktionen med OO-programmering om du lägger alla din kod i void Static Main()-metoden. Enligt ditt exempel så skulle ju HelloWorld exemplet som skriver ut "Hello World" i en Console-applikation (.net) inte vara OO programmering, och det håller jag inte med dig om, programmet behöver inte vara mer komplext än syftet med det, det betyder inte att det inte är OO-programmerat... \- M Permalänk: https://www.webforum.nu/p/2068815 ## #10 — Gladh, 2008-01-08T14:46Z > **niko2k01 skrev:** > > Jag har lite samma problem med OO på webben, och anledningen är att objekten inte (Om jag inte har missförstått) är persistenta, utan måste återskapas för varje instans av en sida. det gör, enligt mig, att lite av fördelarna med OO försvinner. Nja... Jag tycker det går utmärkt att skriva OO kod även för websidor, problemet som du nämner att objekten skapas om istället för att behållas, är ju mer att datat för objektet försvinner, och du måste fylla på data varje gång sidan anropas istället för 1 gång. När jag bygger services som "by default" är stateless så använder jag alltid OO i grunden för att bygga dessa, eftersom det är enklare att jobba med datan i rena objekt än som listor av data i någon form. Det ger mig också en helt annan typsäkerhet och minskar runtime felen. Man får helt enkelt se det som att ens applikation lever en väldigt kort tid och att den har olika startlägen... \- M Permalänk: https://www.webforum.nu/p/2068821 ## #11 — doggelito, 2008-01-08T14:49Z > **Gladh skrev:** > > Den man kan göra här nu för att ÅTERVINNA vår TotPrice() metod är att vi skapar en bas produkt klass Ahha, du tänker så! :bire Bör man, för att undvika att man senare vill bygga ut en klass, alltid skapa basklasser för sina entitetsklasser såsom Product, Category osv.? En annan sak jag funderat på är: Finns det någon vits med att skapa separata projekt i VS för varje entitetsklass? Hur brukar ni göra? Permalänk: https://www.webforum.nu/p/2068824 ## #12 — Gein, 2008-01-08T14:56Z > **Gladh skrev:** > > > **nitro2k01 skrev:** > > > > Man kan mycket väl bara skapa en konstruktor och lägga all kod där à spagettikodning. Även om man använder ett objektorienterat språk betyder det inte att man har följt paradigmen OO för det. > > > Det är OO hur du än vänder och vrider på det, att du sedan skriver dålig OO kod är en annan sak. Du har ju tappat styrkan och funktionen med OO-programmering om du lägger alla din kod i void Static Main()-metoden. > > Enligt ditt exempel så skulle ju HelloWorld exemplet som skriver ut "Hello World" i en Console-applikation (.net) inte vara OO programmering, och det håller jag inte med dig om, programmet behöver inte vara mer komplext än syftet med det, det betyder inte att det inte är OO-programmerat... > > \- M Som nitro2k01 säger så är det fortfarande en tolkningsfråga. När är något objektorienterat, när språket man skriver det i är ett objektorienterat språk eller när min lösning är objektorienterad? Som sagt, det går ju fortfarande att koda sekventiellt även om språket är objektorienterat. Permalänk: https://www.webforum.nu/p/2068827 ## #13 — erka, 2008-01-08T14:57Z Nej du ska alltid gå efter devisen premature optimization is the root of all evil. Du ska skapa klasser efter din verksamhet och dina behov. Tycker inte du ska skapa separata projekt till varje entitetsklass. Jag har ett domänlager där mina entiteter existerar, som sedan skapas via olika DAO Permalänk: https://www.webforum.nu/p/2068829 ## #14 — Gladh, 2008-01-08T15:00Z > **doggelito skrev:** > > Bör man, för att undvika att man senare vill bygga ut en klass, alltid skapa basklasser för sina entitetsklasser såsom Product, Category osv.? Nope, om du inte redan vet med dig att du kommer att behöve olika versioner så finns det ingen som helst anledning att lägga tid på det. Don't over do it. > **doggelito skrev:** > > En annan sak jag funderat på är: > Finns det någon vits med att skapa separata projekt i VS för varje entitetsklass? > Hur brukar ni göra? Jag skulle nog inte skapa separata assemblys för varje entitetsklass. Istället så skapra du en basEntityAssembly, där alla dina basklasser kommer att ligga med, och så implementerar du in den i alla din projekt som behöver ha basklasserna. Och sedan får respektive applikation sitt eget EntityProjekt där dessa klasser ärver från basklasserna. Du skall dock utgå ifrån det behovet du har idag, och inte det du kanske kommer att få imorgon, vet du med dig att du har ett behov imorgon så lös det nu om det blir enklare, men vet du inte med dig att det kommer, så lägg inte tid på att göra allt super generellt, det tar bara massa extra tid... \- M Permalänk: https://www.webforum.nu/p/2068830 ## #15 — Gladh, 2008-01-08T15:04Z > **Gein skrev:** > > när språket man skriver det i är ett objektorienterat språk eller när min lösning är objektorienterad? > Som sagt, det går ju fortfarande att koda sekventiellt även om språket är objektorienterat. Först så har du sekvetiell kod även i bra skriven OO-kod, det kommer du aldrig ifrån. Men den sekventiella kod som du säkert hänvisar till, är enligt mig bara dåligt uttnyttjande av OO styrker och fördelar, det blir inte mindre OO för det, bara dålig OO. Men det är ju min åsikt. \- M Permalänk: https://www.webforum.nu/p/2068833 ## #16 — doggelito, 2008-01-08T15:16Z Okidoki! (uj uj uj, vad jag lär mig mycket idag!) :D En liten fråga till: Har jag förstått rätt att man inte bör lägga sin affärslogik i entitetsklasserna? Ex. GetProductById(int id) ska inte ligga i klassen Product utan i en egen klass, typ: ProductManager? Om det är rätt att ha en ProductManagerklass, bör man lägga den i ett eget assambly eller är det ok att den ligger tillsammans med Product i entitetsassamblyt? Permalänk: https://www.webforum.nu/p/2068835 ## #17 — Gladh, 2008-01-08T15:22Z > **doggelito skrev:** > > En liten fråga till: > Har jag förstått rätt att man inte bör lägga sin affärslogik i entitetsklasserna? > Ex. GetProductById(int id) ska inte ligga i klassen Product utan i en egen klass, typ: ProductManager? Det tvistar de lärda om, vissa vill ha all sin logik i sina klasser, andra vill ha speciella klaser som opererar på entiteter (databärare). Vilket som är bäst beror nog på hur problemet ser ut som du skall lösa. > **doggelito skrev:** > > Om det är rätt att ha en ProductManagerklass, bör man lägga den i ett eget assambly eller är det ok att den ligger tillsammans med Product i entitetsassamblyt? Jag skulle lagt den i ett BLL-assembly medans min produt hade placerats i entityassemblyt. \- M Permalänk: https://www.webforum.nu/p/2068839 ## #18 — erka, 2008-01-08T15:33Z Du kan kolla designmönstrena facade, service interface, dao, personligen trivs jag med service interface som skapar upp olika dao's Permalänk: https://www.webforum.nu/p/2068845 ## #19 — freguz, 2008-01-08T15:45Z Jag började titta på NHibernate för nåra dar sen o kan rekommendera det starkt, dvs det gav mig lite mer OO tänk ialla fall (tror jag). Jag gör numera rena mappningsklasser mot db-tabellen, tex Product och sen har jag en ProductManager klass som har lite fiffig logik och som använder Product som en ren abstraktion av db-tabellen och det är ju så smidigt med NHibernate. Fast jag vet inte om jag tänker rätt alltså, jag bara vill poängtera att jag fått aningen mer OO i knoppen :bire Permalänk: https://www.webforum.nu/p/2068852 --- Tråden på webben: https://www.webforum.nu/amne/dotnet/167879-oo-i-webbvärlden