Jag tänkte sätta tänderna i ett nytt projekt och ska försöka skriva lite bättre strukturerad kod än hittills för att lära mig. :) Däremot vill jag inte komplicera till det för mycket heller så or-mappers och sådant tänkte jag ändå låta bli, jag vill göra det "rätt" men utan att dra på storsläggan så att säga... Det är och kommer alltid att vara ett litet enmansprojekt med samma databas i grunden.
Grunden i min applikation är förstås användarna så jag tänkte börja i den änden och skapa en klass för mina användare. Så här tänkte jag mig det hela:
aspx-sidan ---> user class --> database class
Säg att jag vill spara en ny användare. Som jag tänker det så har jag två angreppssätt:
Alt 1:
User u = new User();
u.NewUser(FirstName, LastName, Company);
Alt 2:
User u = new User();
u.FirstName = FirstName;
u.LastName = LastName;
u.Company = Company;
u.SaveUser();
Vilket av alternativen är bäst? Eller ska man göra på något helt annat vis? Och hur läöser man det bäst om exempelvis Company inte ska vara obligatoriskt? Ska man overrida metoden med/utan company eller skicka in en tom sträng?
En fråga också gällande databasklassen... ska man använda stored procedures eller skapa frågorna i koden eller en kombination? Säg att user-klassen har en update-metod där man ibland bara vill uppdatera enskilda uppgifter, ibland alla. Ska man då hantera alla olika kombinationer med logik i själva sp:n eller dynamiskt bygga upp en sql-fråga i update-metoden eller finns det något annat sätt?
Tack för svar! Jo, jag har ju läst lite om hur ni jobbar med nhibernate (och något alternativ som jag inte kommer ihåg namnet på) men är det verkligen motiverat om det är ett litet enmansprojekt? Blir det inte en väldig massa overhead?
Det tar lite tid att skapa xml mappningarna, men säg en timme kanske, det har du nog gott o väl igen sen. Det är ju lite nytt att lära in, så det kanske är det som tar lite tid, fast det är nog perfekt att köra inlärning i ett litet enmansprojekt, sen finns ju WF för att få snabba svar :)
Om du använder .NET 3.0 så hade jag valt alternativ 3.
User user = new User(){FirstName = "Kalle", LastName = "Eriksson", Company="Företag"};
Där din kod User klass ser ut så här.
public class User{
#region -- Properties
public string FirstName{get;set;}
public string LastName{get;set;}
public string Company{get;set;}
#endregion
}
Det är allt som behövs, men då måste du använda .NET 3.0 Om du inte gör det så förspråkare jag alternativ 1. Fördelen med .NET 3.0 är att du får med Linq To SQL som du kan använda istället för NHibernate, inte alls lika kraftfull men om det bara är ett miniprojekt så duger det säkert bra...
Jag använder .net 3.5 så jag antar att det funkar där med... :) Har #region någon betydelse eller är det bara en slags kommentar?
Projektet kommer inte att bli jättestort eller så men vissa sql-frågor kommer nog att bli ganska komplexa ändå med joins, gruppering, temp-tabeller, dynamisk sql etc så jag vill ha bra kontroll på mina sql-frågor. Funkar Linq ändå?
En till fråga, säg att varje användare kan låna böcker. Ska man ha en AddBooks() i User-klassen eller ska man ha en egen klass Books som på något sätt behöver veta vilken användare böckerna ska lånas ut till?
