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: SnowJim | den 28 november 2008 Kl 16:05
Citerar vimpyboy:


Vad är lättast, att ha 100 stored procedures i SQL Server och 100 i MySQL (alla med samma namn och parametrar), eller att ha kanske 1000 SQL-satser i koden för vardera DBMS? Genom att ha allt samlat blir det lätt att återanvända samma stored procedure, samtidigt som det blir oerhört mycket lättare att byta mellan två DBMS.


Allt beror på omständigheter, man kan oftast inte säga att metod A är bättre än metod B alltid.

Det flesta projekt jag byggt så har det alltid varit spikat vilken databas som ska användas och då ha lagerindelningen egentligen främst inneburet ett vis att dela in problemen i.

Om man tror att databasen mycket väl kan bytas ut i framtiden så måste man väga de olika lösningarna mot varandra. Som du säger så behöver vi kanske 100 storedprocedures i MSSQL databasen och 100 storedprocedures(som gör samma sak) i MYSQL databasen.  Detta innebär att man måste ha full koll på syntaxen för de båda databaserna(då de skiljer en aning), d.v.s man måste göra updateringar i båda databaserna och man måste tänka igenom fuktionen 1 extra gång.

Hela tanken med LinQ To SQL och Entity Framework är vad jag förstått att man ska inte behöva fundera på hur det görs utan bara att det görs. Så omjag säger till ett object att spara sig så vill jag inte bry mig om hur detta sparas (Deklarativ programering?).

Nu är jag inte så insatt i Entityframework, men visst borde det vara så att det kan finnas en provder för MSSQL och en annan för MySQL. När man då kör Save() på objektet så bör man inte behöva by sig om hur det hanteras utan detta sköter providerna som man valt för tillfälligt. Detta betyder isåfall at jag som programerar behöver inte lägga massor med tid på att lägga upp rutinerna. Det är givetvis inte alltid så enkelt.

Citerar vimpyboy:


Linq to SQL känns lagom förlegat, det känns som att de hade kunnat skippa det och gått på Entity Framework direkt.


Än en gång så handlar det om vad man ska göra, enligt Microsoft själva så kan LinQ to SQL användas för små projekt som kräver snabb programering och där databasen är "domain model". EntityFramework är därmed för motsatsen av projekt.

[famous]

Default.aspx.cs
Jag har noterat att du använder ex <%#Eval("Rubrik") %> och visst det fugerar, men enligt min erfarenhet så är det bättre att använda ex en asp:label eller vad du nu vill ha. Anledningen är enkel : "Refactor" - Vill du ändra på ett namn för propertyn senare så kommer inte refactor fungera. Närmare bestämt, jag använder aldrig själv Eval nu för tiden.

Förövrigt har jag inte orkat gå igenom koden i detalj, men det som jag sett är helt okay. Ska man vara petig så är inte namnsättningen perfekt, men jag antar att det är ett test projekt.

Skriven av: famous | den 28 november 2008 Kl 16:08
Jo, det är ett testprojekt så namnen är ju satte innan jag varit helt klar med vad jag egentligen ska bygga ^^

Så du menar att jag lägger in en label och sedan ifrån aspx.cs skickar in rubriken till önskad label istället? Typ lblMinLabel.Text = objP.Rubrik; ?
Skriven av: vimpyboy | den 28 november 2008 Kl 16:15
Just Linq to SQL är skapat just för SQL Server, medan Linq to Entities är större och mer skalbart. Det finns många diskussioner om varför Microsoft ens fortsätter med Linq to SQL då Entity Framework är mycket bättre på alla sätt, samtidigt som det är mer skalbart (Entity Framework 2.0 kommer att vara riktigt skalbart, och man kommer att på ett riktigt snyggt skapa upp egna typer och mappa mot databaser).

Det stämmer att man inte ska behöva anropa databasen direkt, utan skall kunna köra t.ex.:

Kod:
User user = Users.GetUSer(123);
user.Name = "Nisse";
user.Save();



Vad som sker där är att den hämtar den databas som ska användas (kan ske genom t.ex. en nyckel i web.config och sedan genom en klass som håller reda på dessa och kör rätt kod).

När man kör med t.ex. Entity Framework så måste man fortfarande specifiera vilken databas och vilka tabeller/sprocs som skall användas.

Har man skrivit ett skalbart system så blir det sedan inga problem att byta till en annan databas-provider. Dessa providers bör implementera ett interface för att man alltid skall kunna anropa en metod och vara säker på att den finns i den aktuella providern.
Skriven av: vimpyboy | den 28 november 2008 Kl 16:16
Citerar famous:

Så du menar att jag lägger in en label och sedan ifrån aspx.cs skickar in rubriken till önskad label istället? Typ lblMinLabel.Text = objP.Rubrik; ?


I ItemDataBound så kan du hämta yadda[e.Item.ItemIndex].Rubrik och på så sätt kunna sätta värdet från code behind.
Skriven av: famous | den 28 november 2008 Kl 17:25
Allright, ska lägga på minne :) Tack
Skriven av: Pbf | den 30 november 2008 Kl 23:19
Citerar vimpyboy:


Jag hade nog skapat ett interface för meddelandeklassen, t.ex. IMessageFactory. Sedan hade jag implementerat det i klassen. På så sätt kan jag enkelt skapa flera MessageFactory-klasser som går mot olika datakällor.


Hade du döpt respektive klasser som implementerar "IMessageFactory" till MySqlMessageFactory, precis som exempelvis MySqlDataReader som implementerar IDataReader? Om jag döper fel blir jag bara förvirrad... :)
Skriven av: vimpyboy | den 30 november 2008 Kl 23:34
Ja.
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 1,0781 sekunder att ladda sidan