Det jag vill med COM+ är att testa olika former att bygga en DAL(Data Access Layer). Funderat på vilken som är den bästa lösningen med tanke på prestandard. Men har ännu inte kommit fram till något vettigt. Den ska fungera som så att man skickar parametrar och namnet på den "sparade proceduren"(stored procedure) och man får tillbaka en uppsättning data. Har testa med att retunera DataTable och DataSet och det fungerar riktigt bra så jag kommer hålla mig till det och placera connectionstringen utanför root i en .xml fil, krypterad om nödvändigt.
Session Connectionstring
22 svar · 399 visningar · startad av Nickemannen · sida 2 av 2
Visst kan man använda COM+, men vad tillför det egentligen som du inte kan göra med Registry?
Det är bra mycket enklare att konfigurera COM+ än registret. Där jobbar du ju visuellt och klickar i och fyller i rutor i motsats till registret.
Dessutom antar jag att prestandan bör bli bättre med COM+ än med registret då COM+ och "object Construction" är byggt för att hantera att strängar skickas till komponenter vid instansiering.
Nån direkt URL till just detta har jag inte (har själv lärt mig på kurs...), men du kan läsa allmänt om COM+ och .NET på:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/comservnet.asp
SPiN skrev:
Men vill man vara riktigt, riktigt, riktigt säker så ska man nog kompilera hela rubbet.
Det är ju det jag säger hela tiden! Affärslagret = dina bakomliggande komponenter. :)
Men om du måste ändra din datakälla så måste du kompillera om affärslagret. Då är det nog bättre att det sparas i en XML fil. För om du har det i en XML fil och ändrar i den så kommer ändringen gå igenom på en gång. Men en sak kan vara lite dumt med XML fil, det är att verje gång den man ska öppna en databaskoppling måste läsa en fil för att få connectionstring. Lösningen på det är att i global.asax, man läser in den i ett application object och hämtar den därifrån. Och varje gång du ändrar XML filen så kör du bara en viss sida som hämtar den nya connectionstringen.