Sök  
 
Skribent Inlägget Löst
Google
 
     

  Forum » .NET 3.5 » Allmänt .Net tänk  
 
Skriven av: famous | den 24 november 2008 Kl 14:49
Allmänt .Net tänk
Tänkte bara plöja genom lite saker här i en och samma tråd, så man kan få svar man själv förstår.

Har som sagt nyss börjat försöka mig på .Net (3.5) och det hela är ju otroligt annorlunda från gamla ASP. Kul, men också frustrerande.

Jag känner mig inte helt hemma med tänket, men som jag förstått det så är den s k treskiktslösningen alltså .aspx, aspx.cs och sedan .cs filerna som ligger och jobbar i App_Code?

Hur bör man bäst lägga upp strukturen här och hur ska man arbeta med namespace etc på ett bra sätt?

Nedan är lite frågor och påståenden ni gärna får rätta mig på.

1) .aspx filen innehåller lite kontroller och html-koden som besökaren möts av.
2) .aspx.cs innehåller lite events som .aspx filen är kopplad mot. Alltså finns en .aspx.cs för varje .aspx som innehåller de events som behövs för just den sidan.
3) Vad tusan är aspx.designer.cs?
4) I App_Code lägger man filer som innehåller klasser, som i sin tur innehåller metoder och tjosan för att tex hämta data, öppna databas och annat?
5) Är en smidig struktur då att ha en .cs fil för de olika sektionerna på sidan, tex Forum.cs, Nyheter.cs osv? Ska då dessa ha olika namespace?


Vad bör man lägga vart i denna strukturen? Ska man dela upp det ännu mer än vad jag nämnt redan?
Är ett bra sätt att från aspx.cs anropa något i tex Nyhet.cs, och där sker SQL-kommandon osv, eller ska man ta det ett steg längre / kortare?

Hur fungerar namespace lite mer ingående och vad bör man tänka på?


Finns säkert redan svar på allt jag frågar om, men gör ett försök iaf då det är skönt att få allt samlat.

Antal svar 47



NAVIGERING: 1 2 [3] 4 5
Skriven av: Stefan | den 25 november 2008 Kl 10:50
Nej det har han ju inte alls. Du har ju precis lika.
Nyhet.cs = Post.cs
Data.cs = DbOps.cs

Jag skulle rekommendera att du har en klass som är en NewsCollection, som ärver List<News> (eller IEnumerable<News> om Vimpy får bestämma). Denna klass kan du sedan använda för att databinda din repeater. Kan se ut ungefär såhär:

Kod:

protected void Page_Load(object sender, EventArgs e)
{
  if (!IsPostBack)
  {
  NewsCollection nc = new NewsCollection();
  nc.GetAll();
  Repeater1.DataSource = nc;
  Repeater1.DataBind();
  }
}

Skriven av: vimpyboy | den 25 november 2008 Kl 10:52
I code behind kan du ha något i stil med:

Kod:
News news = new News(); //Mycket new där. ;-)
rptYadda.DataSource = news.GetItems(20); //Anropar News.GetItems(int count) som returnerar t.ex. IEnumerable<NewsItem>
rptYadda.DataBind();



I NewsItem skulle du kunna ha metoder för t.ex. Save, Update, Delete m.m.

Redigerad av: vimpyboy
Lite seg. =)

Redigerad av: vimpyboy
För att gå mer på Stefans spår så skulle du kunna returnera en NewsCollection från GetItems, som i sin tur implementerar IEumerable<NewsItem>.
Skriven av: famous | den 25 november 2008 Kl 11:16
Citerar Stefan:


Nej det har han ju inte alls. Du har ju precis lika.
Nyhet.cs = Post.cs
Data.cs = DbOps.cs


Fast, i min Data.cs har jag ju bara anslutning till databas och lite sånt?  
Han kör ju alla SQL uttryck i DpOps.cs, de kör jag i Nyhet.cs

Skriven av: Stefan | den 25 november 2008 Kl 11:20
Jag gör som du! Tycker det verkar korkat att ha SQL-uttrycken i sitt DAL, då blir det ju väldigt applikationsspecifikt, och jag vill använda mitt i alla mina projekt.
Skriven av: BlackMustard | den 25 november 2008 Kl 12:40
jag har nyligen blivit förälskad i ADO.Net Linq to Entities, där man i VS/VWD (vet dock inte säkert om det funkar i den senare) skapar ett datalager som läser av strukturen i en databas och mappar upp klasser för varje objekt. det gör mycket av jobbet gratis, även om det kan vara bra att ha lite kläm på vad det är man vill åstadkomma i form av uppdelning så småningom.
Skriven av: vimpyboy | den 25 november 2008 Kl 12:48
Linq to Entities fungerar bra och är smidigt, men det har sina nackdelar.. Varje gång jag sätter igång med det hittar jag en ny bugg, men då försöker jag iofs göra "skumma" grejer. Om man har en normal och välstrukturerad databas så fungerar det dock helt ok.

Det går med EF att få bort nästa hela databaslagret och istället jobba mot det direkt från BLL och där returnera egna typer om man nu önskar det.
Skriven av: SnowJim | den 25 november 2008 Kl 14:43
famous - Det låter som att du är ganska ny på ASP.NET därför tycker jag att du tar ett steg för långt.

Strunta i hur designen på sidan ska se ut, strunta i de nya teknikerna, prova bara att bygga några enkla mindre sider(utan någon avancerad layout och grafik). Detta kommer lärs dig en hel del om själva ASP.NET och dess flöde. När du känner att grunderna sitter så tar du nästa steg(vad det nu kan vara för din del).

Angånde var SQL frågorna ska ligga så är det en klurig fråga. De hör på sätt och vis till Business logiken men samtidigt är de knutna till databasen som används, dessutom är inte SQL något som rent tekniskt hör hemma i Business Layer.

Man skulle dock kunna lägga till ett lager till mellan DAL:et och Business lagret där SQLen generas/byggs upp, men det kan ses som lite overkill.

Även om jag inte själv skulle lägga SQL i något annat lager än DAL:et så kan jag ändå se att det är en fråga som man får ställa sig från gång till gång.
Skriven av: Stefan | den 25 november 2008 Kl 14:45
I en perfekt värld använder man ju Stored Procedures och parametrar, så man inte är beroende av vilken databasmotor man använder iallafall.

Därför tycker jag absolut att det ska hållas borta från DAL. Sen att det kanske inte passar riktigt i BLL heller, det kan jag väl hålla med om, men där har jag mitt iaf
Skriven av: vimpyboy | den 25 november 2008 Kl 15:02
Självklart skall man använda stored procedures, men det gäller inte bara när man använder databaser med ASP.NET, utan även när man bara använder databasen som den är, och när man är gammalmodig och kör ASP.
Skriven av: SnowJim | den 25 november 2008 Kl 15:06
Stored Procedures hare sina fördelar utan tvekan, men det innebär tyvärr också ofta att man riskerar att förlora gränserna och därmed lägga lite verksamhets logik i dessa procedurer.

Om man dessutom har byggt upp sina spar rutiner i databasen så betyder det att du har ett ganska omfattande jobb om du helt plötsligt ska gå över till en annan databasmotor. För man kan väll inte bara skicka över sina stored prcedures från MS SQL till MySQL eller tvärtom?

Allt beror på hur det ska användas, vilke framtidsplaner som finns o.s.v. Jag ser inte att något vit är direkt dåligt, det gäller bara till att anpassa till situationen.

Får man föresten fråga hur du gör med LinQ to SQL? denna teknik genererar ju SQL frågor som skickas till databasen. Detta betyder att på en entitet så väljer man Save() och sen fixar den resten. Menar du då att detta gör du uppe i BLL? Vad används isåfall DALet till? Och var hamnar dina entiteter?
NAVIGERING: 1 2 [3] 4 5
 
     

  Svara på inlägg  
 
Du måste vara medlem på ASPsidan för att kunna skriva i forumet.
För att bli medlem klicka här.
 
     

  » Logga in  
 
Användarnamn

Lösenord

 
     

  » Bli medlem  
  Bli medlem på ASPsidan!  
     

     
  Microsoft  
     

  » Partners  
  Comsolvia  
     
  » ANNONS  
  ingen annons än  
     

  » Senast online  
  Endast för inloggade  
  Antal inloggade: 1  
     

Copyright © 2007 www.ASPsidan.se
ingen sponsrar längre ASPsidan med Dedikerad Server
ASPsidan RSS
   
 XHTML / CSS
Det tog 0,4531 sekunder att ladda sidan