Gör om gör rätt, eller?

Hmm var ska jag börja, har ju precis satt igång själv med det här...

Det du ska göra är att starta ett nytt webapplication project med följande "delprojekt"

1. Entities
2. DAL
3. BLL
4. UI

Entiteterna blir då en klass för varje sida. Varje klass i Entitet projektet ska ha funktioner för get/set så att du enkelt kan skapa en IList med resultaten från ditt DAL. Utan detta projekted är du tillbaka där du är nu. Då spelar det inte så stor roll med ditt dal och bll.

DAL projektet ska innehålla dataåtkomst och mappa upp datan mot ditt Entitets projekt. Dvs du hämtar ett datatable från din MySQL databas och returnerar en IList.

BLL projektet kommer se ut som en kortvariant av din DAL och bara referera till denna och returnera din IList till ditt UI Projekt. Efter ett tag kommer du validera alla typer av inputs som kan generera felmeddelande (som ditt UI projekts klientbaserade validering har missat)

Sist men inte minst har vi då ditt UI (User Interface) dvs dina aspx sidor som presenterar ditt community för användaren. Det är du säkerligen väl förtrogen med men här ska du inte ha någon logik alls egentligen, den ska hämta all data från ditt affärslager (BLL) som i sin tur hämtar från DAL och mappar upp mot dina entiteter.

Det finns ingen bra läsning och du ska definitivt undvika dataset så långt det går. Jag skulle inte bygga upp dataåtkomsten (DAL) med ett dataset därför att det dels inte är logiskt samt dels är väldigt prestandakrävande. /edit: särskrivning

I följande tråd http://www.webforum.nu/showthread.php?t=163055 så har jag fått de flesta svar jag behövde på hur jag ska bygga upp en n-tier webb aplikation på ett vettigt sätt. Det finns även lite på samma spår i följande tråd http://www.webforum.nu/showthread.php?t=163625

Kolla de trådarna så får du säkert lite idéer på hur du ska sätta igång.

Jag har förresten ett projekt till i mitt web application project.

5. AccessProvider

Därför att jag måste använda access databas då inte många webhotell stöder gratis MS SQL.

Tack för de svaren, det ska väll tilläggas att det var dina trådar som fick mig att börja tänka efter. ;)

Din förklaring var mycket bra så till och med jag förstod, men har fortfarande några frågetecken. Vi kan väll säga att jag ska skapa en blogg, en gästbok och ett klotterplank så blir det enklare för mig att förklara.
- Bloggen består utav 3 sidor. En sida där alla blogg inlägg listas, en där man kan redigera/skapa ny och en annan där alla bloggar från alla medlemmar listas.
- Gästboken består bara utav en sida, men jag har paging på gästboks inläggen som jag skapar tillhjälp utav MySQLs LIMIT och sedan en annan kod för att räkna ut hur många sidor det är osv.
- Och sen klotterplanket består utav bara en sida och som hämtar de 20 senaste inläggen.

Entities - Om det nu ska vara en entites för varje sida ska jag då ha en för blogg funktionen, en för gästoken och en för klotterplanket. Eller en för alla 5 .aspx sidor?
Så som jag ahr uppdattat det som så ska det vara en get, set för varje column i databasen som man kan behöva använda, eller?
Om vi säger att klotterplankets tabell har kolumnerna id, fromUserID, date ska det då vara så här:

private int _ID = 0;
protected int ID
{
 get { return _ID; }
 set { _ID = ID; }
}

private int _fromUserID = 0;
protected int FromUserID
{
 get { return _fromUserID; }
 set { _fromUserID = FromUserID; }
}

private DateTime _date = 0;
protected DateTime Date
{
 get { return _date; }
 set { _date = Date; }
}

Eller har jag förstått det där fel?

Sen DAL så hade jag lite svårt att förstå vad du menar. Men kollade på det här som Gladh skrev:

public class DAL{
 
 public List<Person> GetAllPersons(){
  
   //-- Här gör du en databas fråga mot din databas som hämtar all Person data från databasen till ett DataTable.
   ...
   ...

  //-- Här loppar vi igenom vårt DataTable och skapar våra Person objekt.
  List<Person> personList = new List<Person>();

  for(int i = 0; i < dataTable.Row.Count; i++)
  {
     Person person = new Person();
     person.Name = dataTable.Row[i].Column["Name"];
     person.Age = dataTable.Row[i].Column["Agr"];

     personList.Add(person);
  }

  return personList;
 }
}

Betyder inte det att jag måste göra en DAL för varje sida också? Ska jag försöka sattsa på en entities, en DAL, en BLL för varje sida (sen vad som defineras för sida vet jag inte.) Eftersom att projektet är stort så kanske det är bäst?

BLL och UI sitter tror jag. :)
/ Timmie

theVice skrev:

Entities - Om det nu ska vara en entites för varje sida ska jag då ha en för blogg funktionen, en för gästoken och en för klotterplanket. Eller en för alla 5 .aspx sidor?

Nope, nej, icke, aldrig....

Dina entiteter/klasser har absolut inget med dina sidor att göra utan representerar istället de objekt som du behöver för att skapa dina sidor, det betyder att en sida kan behöva använda sig av 10 olika entiteter och en entitet kan användas på 10 olika sidor. För att du skall förstå vad entiteter/objekt är så krävs det att man förstår grundläggande objektorientering, gör du inte det, så börja där.

I ditt fall med dina 3 sidor, så skulle du faktiskt kunna klara dig med 2 entiteter. En som heter User och en som heter Information (eller något annat fyndigt namn). Din Information entitet kan nämligen hålla all data för din blog, gästbok och klotterplank. Då informationen till dessa entiteter är iprincip är den samma.

- Rubrik
- Meddelande
- Datum
- User.

Så entiteter har inget med dina sidor att göra, sidorna använder entiteterna för att presentera information, entiteterna är bara bärare av information på ett strukturerat sätt.

theVice skrev:

Betyder inte det att jag måste göra en DAL för varje sida också? Ska jag försöka sattsa på en entities, en DAL, en BLL för varje sida (sen vad som defineras för sida vet jag inte.) Eftersom att projektet är stort så kanske det är bäst?

Nope, nej, icke, aldrig....

Ditt DAL och ditt BLL och dina sidor har egentligen ingetting gemensamt. Du kan inte skapa ditt BLL utifrån dina sidor, utan utifrån den information som du behöver använda dig av, om det sedan presenteras på 10 olika sidor eller 1 sida, eller i en WinApplikation eller varför inte i WAP-läsare är ointressant. Dina lager får under inga omständigheter känna till något om lagret "över sig". Ditt presentations lager känner till ditt BLL på så sätt att den vet vilka metoder som den kan anropa, men metoderna är inte skrivna utifrån dina sidor. Likadant med ditt DAL den känner inte till ditt BLL, medans ditt BLL kan anropa metoderna i ditt DAL men återigen så är inte DAL:et skriviet utifrån hur ditt BLL agerar.

Så när vi tagit den korrekta versionen, så vet alla att så inte är fallet och man allt som oftas sitter och skriver en metod hela vägen ner genom lagrerna.

- M

Vilken intressant tråd det här kan bli, får man vara med på ett hörn? :) Jag har nämligen också ett projekt (en slags community) jag vill skriva om för att lära mig använda OO på ett seriöst sätt. Det som känns mest akut är hur jag ska hantera mina användare på ett bra sätt. Dels behöver jag förstås kunna hantera enskilda användare men också grupper av användare. Idag har jag en klass som sköter kopplingen mot databasen (använder bara SPs), annars ligger nästan all kod bakom respektive aspx-sida.

Hur börjar jag? Ska jag ha två klasser, User och Users? Och ska Users bara vara en lista av User?

En annan fråga, ska man sträva efter att ha nästan ingen kod alls bakom sina aspx-sidor? Tänkte exempelvis på en egen custom paging som jag gjort. Där använder jag flera asp:hyperlinks och en repeater för att få ihop den. Hur skulle man göra för att lyfta ut den från sidan och in i en klass? Den är ju så tajt kopplad till asp.net-kontrollerna lokalt på sidan? Hur ska man tänka?

Tack Gladh det börjar klarna nu, har alltid undrat vad folk menar med att man in princip kan använda sitt DAL igen. Men nu förstår jag.

Jag satt och kollade på koden till TheBeerHouse, men jag tror inte det riktigt är uppbyggt på samma sätt. Någon som kan tipsa om kod exempel/ artiklar så jag vet hur jag ska göra för att klara av de 4a lagerna? Nu vet jag pseudokoden men inte hur man ska göra i praktiken.

Sen som Gladh säger så är väll det bästa att kunna objektorientering, länk tips till det?
Som sagt min kunskap ligger där jag är nu, men det handlar väll om att utvecklas? :)

För att spinna vidare på det Gladh skriver så kan ju tilläggas att man ska programmera på ett sådant vis att det blir enkelt att byta ut sitt DAL om man byter databas, eller sitt UI om man nu vill skapa en Windows Forms Application istället. Då ska du kunna återanvända koden från de andra lagren egentligen helt utan att göra några ändringar annat än i det lagret du byter ut.

Det är sant som Gladh skriver, man ska absolut inte stirra sig blind på per sida utan mer tänka på informationen man behöver och gruppera baserat på informationen som ska presenteras.

I mitt fall News (som trådarna handlar om) så gör jag en enkel join mellan news och users och behöver egentligen inte använda mig av Entiteten Users eftersom min nyhetsdel är så himla simpel. När du gör en mer avancerad presentation som i ditt fall på en blogg är det inte fel att dela upp entiteterna på tex User och Information.

Din DAL kan ju därför referera till 2 olika entiteter i fallet ovan. När jag gör wexiö bridgens förstasida så kommer jag hämta information från många entiteter, news, results, users, därför kommer jag också anropa flera olika DAL eftersom jag vill återanvända koden som jag redan skapat på dessa sidor.

Som alltid när du ska "göra om, göra rätt" så måste du planera ordentligt i förväg. Själv är jag dålig på det men har börjat på de sidor som är enkla dvs bara använder sig av ett DAL, en entitets typ och ett bll. För att sedan återanvända detta på de sidor där jag kan. Skulle jag tex starta med första sidan skulle allt förmodligen bli tokigt rörigt då jag förmodligen inte skulle lyckas återanvända nämnda klasser på andra sidor.

inspiro skrev:

Hur börjar jag? Ska jag ha två klasser, User och Users? Och ska Users bara vara en lista av User?

Nu tänker du fel, det ska bara vara en klass om det är Entiteterna du tänker på. Listan skapas sedan genom att mappa upp entiterna från ditt DAL. Däremot så rekommenderar jag att du använder dig av Web Application Projects då det efter mycket klurande blir mer överskådligt.

inspiro skrev:

En annan fråga, ska man sträva efter att ha nästan ingen kod alls bakom sina aspx-sidor? Tänkte exempelvis på en egen custom paging som jag gjort. Där använder jag flera asp:hyperlinks och en repeater för att få ihop den. Hur skulle man göra för att lyfta ut den från sidan och in i en klass? Den är ju så tajt kopplad till asp.net-kontrollerna lokalt på sidan? Hur ska man tänka?

Jag är inte riktigt med på vad du menar här... hur ser det ut i code behind?

thevice skrev:

Någon som kan tipsa om kod exempel/ artiklar så jag vet hur jag ska göra för att klara av de 4a lagerna? Nu vet jag pseudokoden men inte hur man ska göra i praktiken.

Kolla i zipfilen som följer med inläggen, jag kom ihåg bara att filerna ligger i olika projekt och har olika namnrymder men det borde ge dig en hum om hur du kan sätta igång. Som jag skrev tidigare så är planering allt!!

thevice skrev:

Sen som Gladh säger så är väll det bästa att kunna objektorientering, länk tips till det?

http://www.4guysfromrolla.com/webtech/091800-1.shtml
för lite mer info om OO. När det gäller sättet att koda på som tex Gladh gör så verkar det inte läras ut på internet... jag har i alla fall inte hittat en enda sida som visar hur man VERKLIGEN ska göra... alla använder sig av äckliga dataset och det vet jag av egen erfarenhet dödar en större applikation...

CatZ skrev:

Nu tänker du fel, det ska bara vara en klass om det är Entiteterna du tänker på. Listan skapas sedan genom att mappa upp entiterna från ditt DAL. Däremot så rekommenderar jag att du använder dig av Web Application Projects då det efter mycket klurande blir mer överskådligt.

Vet inte riktigt vad som menas med entiteter. Genomgående för alla sidor i mitt projekt är att jag behöver hantera mina användare på olika vis. Allt från att på varje sida kontrollera om användaren är inloggad, hur många mail h*n har i sin inbox, vad användaren har för inställningar osv osv. Men jag hanterar ju också grupper av användare, exempelvis om jag ska lista alla användare med vissa egenskaper. Jag behöver alltså få fram information både om enskilda användare och grupper av användare.

Idag hanterar jag det så att på respektive sida anropar jag min databasklass där jag skickar in namnet på min sp. Ska jag ta bort en användare anropar jag mitt dal och skickar in namnet på den sp som tar bort användaren tillsammans med andra nödvändiga parametrar. Ska jag hämta en grupp användare skickar jag in namnet på den spn tillsammans med nödvändiga parametrar i just det fallet och då returnerar min db-klass en datatable som jag sedan hanterar lokalt på den sidan.

Jag förstår inte riktigt hur jag ska bygga en generell klass när man jobbar med stored procedures eftersom de är så ändamålsspecifika!?

CatZ skrev:

En annan fråga, ska man sträva efter att ha nästan ingen kod alls bakom sina aspx-sidor? Tänkte exempelvis på en egen custom paging som jag gjort. Där använder jag flera asp:hyperlinks och en repeater för att få ihop den. Hur skulle man göra för att lyfta ut den från sidan och in i en klass? Den är ju så tajt kopplad till asp.net-kontrollerna lokalt på sidan? Hur ska man tänka?

Jag är inte riktigt med på vad du menar här... hur ser det ut i code behind?

Jag har en dataview som visar upp en lista. Eftersom listan kan innehålla väldigt många poster så bestämde jag mig för att göra en custom paging så jag slipper hämta 1000-tals poster och ändå bara visa upp 20 i taget. Pagingen fungerar jättebra men den är ju väldigt hårdkodad på just den här sidan. Under min dataview så har jag dels 4 stycken asp:linkbuttons (en för första sidan, för nästa, för föregående och sista) samt en repeater som innehåller länkar till plus/minus 5 sidor runt den aktuella sida jag står på (navigeringen fungerar som webforum ungefär alltså).

Koden för den här funktionaliteten ligger direkt bakom aspx-sidan där navigeringen finns. Klickar jag på nästa-knappen så har jag ett onclick-event som med hjälp av min db-klass hämtar rätt poster från databasen helt enkelt. Hur skulle jag kunna lägga detta i en generell klass? Eller ska man ens göra det?

inspiro skrev:

Vet inte riktigt vad som menas med entiteter. Genomgående för alla sidor i mitt projekt är att jag behöver hantera mina användare på olika vis. Allt från att på varje sida kontrollera om användaren är inloggad, hur många mail h*n har i sin inbox, vad användaren har för inställningar osv osv. Men jag hanterar ju också grupper av användare, exempelvis om jag ska lista alla användare med vissa egenskaper. Jag behöver alltså få fram information både om enskilda användare och grupper av användare.

Idag hanterar jag det så att på respektive sida anropar jag min databasklass där jag skickar in namnet på min sp. Ska jag ta bort en användare anropar jag mitt dal och skickar in namnet på den sp som tar bort användaren tillsammans med andra nödvändiga parametrar. Ska jag hämta en grupp användare skickar jag in namnet på den spn tillsammans med nödvändiga parametrar i just det fallet och då returnerar min db-klass en datatable som jag sedan hanterar lokalt på den sidan.

Jag förstår inte riktigt hur jag ska bygga en generell klass när man jobbar med stored procedures eftersom de är så ändamålsspecifika!?

Det är just då du tänker fel. En användare är en entitet och när du mappar upp tex en grupp av användare så kör du den proceduren som hämtar den gruppen av användare, hämtar datan i ditt dal och skapar en IList som mappar mot din UserEntity.

Kolla i zipfilen som jag postade så kanske det klarnar lite...

CatZ skrev:

Det är just då du tänker fel. En användare är en entitet och när du mappar upp tex en grupp av användare så kör du den proceduren som hämtar den gruppen av användare, hämtar datan i ditt dal och skapar en IList som mappar mot din UserEntity.

Kolla i zipfilen som jag postade så kanske det klarnar lite...

Näe, klarnar inte. :) Förstår inte vinsten riktigt... jag ser bara ett extra lager som borde påverka prestandan negativt?

Ta ett enkelt exempel, jag vill veta hur många olästa mail kalle har och skriva ut det på sidan. På ett eller annat sätt måste jag ju hämta det från databasen och det är sql-frågan som gör jobbet. Vad tjänar jag på att ha en entitetklass som inte innehåller så mycket mer än en variabel som jag kan sätta/hämta, jag måste ju ändå vidare och peka på min stored procedure någonstans?

Hm jag brukar lägga upp det typ så här:

En klass "DataLayer" som hanterar alla db anrop (de flesta hämtar bara upp en DataTable).

Sen har jag ett gäng olika klasser för varje typ av objekt jag vill arbeta med på sajten.

Ofta klasser som "Product", "Category", "User", "Order", "Statistics", "Util", "Settings" osv

Varje klass arbetar mot DataLayer, hämtar o sparar ner, data, och så har jag ganska mycket logik i klasserna, valideringar, sätta lite bekväma booleaner osv, det blir så kladdigt i codebehind annars, där vill man (jag) ha så lite kod det bara går.

Det är så smutt att bara kunna skriva

User U = new User(myCookie);
txtItems.Text = U.Mails.ToString();
txtLatest.Text = U.LatestDateOnline.ToShortDateString();
ImgGreenLight.Visible = U.IsOnline;
...osv

Nu är ju detta inte alls eniteter eller nåt väldigt fiffigt, utan bara ett smidigt sätt som jag gillar att använda :) Och det går fort att bygga ;)

När det gäller paginering just, så bygger jag dom också oftast rakt upp o ner i codebehind men det brukar inte vara så mycket kod, bara ett PagingEvent, kör oftast med DataList eller GridView, att ta hand om så det böket får man ta :)

Men som sagt, Entiter o det där är förstås mycket bättre, jag tänkte också ta o försöka lära mig det där...

Tack CatZ, det är nog så som du säger att om jag ska bygga om så ska jag också planera rätt. Det är därför som jag skapade tråden så jag kan få insikt i hur jag ska göra ett DAL. Hur jag ska planera och framför allt hur jag ska börja.
Har inte hunnit kolla på filerna som du skickade men jag ska börja göra det snarast.

Frågan är hur jag ska börja när jag ska bygga om min sida, hur jag ska börja. Tips?
Ska jag börja göra en mindre sida med ett DAL bara för att få in det eller ska jag gå rakt på sak på sidan och börja göra funktion för funktion? Kanske börja med någon lättare funktion som ett nyhets script och sedan gå vidare.

Jag har fortfarande svårt att förstå hur enti, DAL och BLL hänger ihop. Får hoppas att det klarnar lite när jag ser koden som du skickade med.

Nu så avsätter jag 30-60 minuter om dagen (hälften på morgonen och hälften på kvällen) till att gå igenom dagen, utvärdera vad jag gjort planera om det jag inte gjort . Brukar ta med att hela tiden gå igenom vad som saknas i projektet, vilka funktioner som behövs för att få till det som saknas.

Men när du börjar så är det smidigast om du tittar på en rätt enkelt sida tittar på hur du vill presentera informationen, då får du en inblick i vilken information du måste hämta och då blir det enkelt att ta hand om entiteterna.

I resultat filen som jag postade tidigare så ska jag lyfta ut själva filen till en egen Entitet eftersom jag inte riktigt tycker filen gör sig där.

Det blir för kluddigt att ha allting i samma, visst resultat filen (i binär form) hänger ju definitivt ihop med resultaten men borde nog vara helt standalone för att underlätta underhåll.

Eventuellt skulle jag kanske lyfta ut resultatet till en annan tabell och då kunna spara inte bara resultat utan även bilder och andra filer som laddas upp till servern.

Det kom jag på igår natt när jag "planerade". Eftersom jag redan har delat upp det i ett n-tier projekt så blir det väldigt enkelt att göra själva ändringarna, det är i princip bara att göra cut/paste på de delarna som ska flytts till en egen klass i bll, dal och entity. Hade jag alltihop i codebehind på min aspx sida skulle det vara mycket svårare att göra de ändringarna (gliring till inspiro)

Jag har nu börjat titta på din kod, jag tänkte att jag gör så att jag gör funktion för funktion på det nya settet för om jag skulle börja om från början skulle det inte bli något av det.

Några funderingar bara,
Är det någon skillnad på om man har parametrarna i DAL eller BLL? Vilket är bäst?
Jag tänkte att jag skulle göra ett nyhetsarkiv, men kom sedan på att jag kan använda samma DAL och Entities till forumet, hur är det bäst att döpa sakerna då?
Och vad gör din MapTable?

Om du skall göra om kika på ASP.NET MVC som har släppts som beta nu, riktigt bra måste jag säga :D.

Nickemannen skrev:

Om du skall göra om kika på ASP.NET MVC som har släppts som beta nu, riktigt bra måste jag säga :D.

Antar att det är för .NET 3.5?

Ja det är det, annars kan du alltid kolla in icke ramverksspecifika lösningar/patterns, genom att tex. tillämpa passive view eller supervising controller. Huvudsyftet med de flesta MVC och MVP-mönster är att skapa unittestbara gränssnitt.

vad innebär unittestbara gränssnitt?

Ett stort problem är att det är ett härke att försöka skriva test som verifierar funktionalitet i gränssnittet. Ett unit-test är kod som testar en atomär del av en applikation, en isolerbar liten del. Vanligtvis skriver man kanske unit-test mot sina domänklasser men man är i minst lika stort behov av att göra det för gränssnittet. Med mönster såsom olika specifika varianter av MVC och MVP abstraherar man i så stor grad att denna testning blir möjlig att genomföra. DU använder förslagsvis nUnit och RhinoMocks eller annat mock-ramverk för att kunna skriva dina tester och isolera dem till att endast testa det som ska testas.

Fowler bröt upp MVP till två olika mönster, http://martinfowler.com/eaaDev/PassiveScreen.html och http://martinfowler.com/eaaDev/SupervisingPresenter.html, vilken man bäst gillar är kanske en smaksak.

De flesta buggar som inträffar är enligt min erfarenhet i gränssnittet, skrämmande stor procentdel. Därför är det viktigt att kunna testa dem, och använder man continoius integration med automatiska byggen är det ännu viktigare. Red Green Refactor baby :) Kent Beck har skrivit en fantastisk bok som heter Test Driven Development om du vill veta mer http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530

Tom MS har ju insett behovet av att skriva test under hela utvecklingstiden nu ;)