webForumDet fria alternativet

OO i webbvärlden

.NET

18 svar · 599 visningar · startad av doggelito

Medlem sedan juni 20003 076 inlägg
Frågan#1

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! :)

Medlem sedan feb. 2005280 inlägg
#2

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

Medlem sedan jan. 20023 327 inlägg
#3

Objektorienterad analys och design (OOAD) är grundstenen. En bra början finns här:
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design

Kolla lite sedan på referenserna i artikeln. Börja googla på nyckel-ord/termer och köp en vettig bok.

Jag har denna :)

Medlem sedan juni 20003 076 inlägg
#4

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?

Medlem sedan aug. 20039 340 inlägg
#5

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.

Medlem sedan maj 20012 812 inlägg
#6

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

Medlem sedan aug. 20039 340 inlägg
#7

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.

Medlem sedan maj 20012 812 inlägg
#8

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<Product> 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<BaseProduct> 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

Medlem sedan maj 20012 812 inlägg
#9

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

Medlem sedan maj 20012 812 inlägg
#10

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

Medlem sedan juni 20003 076 inlägg
#11

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?

Medlem sedan sep. 20005 700 inlägg
#12

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.

Medlem sedan dec. 19996 522 inlägg
#13

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

Medlem sedan maj 20012 812 inlägg
#14

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

Medlem sedan maj 20012 812 inlägg
#15

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

Medlem sedan juni 20003 076 inlägg
#16

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?

Medlem sedan maj 20012 812 inlägg
#17

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

Medlem sedan dec. 19996 522 inlägg
#18

Du kan kolla designmönstrena facade, service interface, dao, personligen trivs jag med service interface som skapar upp olika dao's

Medlem sedan feb. 2005280 inlägg
#19

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

264 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
124 ms — deklarationer (db)
0 ms — hämta statistik (cache)
137 ms — hämta tråd, inlägg och bilagor (db)
124 ms — ändringar (db)