DataAccessLayer
private OdbcCommand CreateCommand(str eller cmd) ' Sätter connStr
public void runNonQuer(str eller cmd) {
createCommand(param0).executeNonQuery()
}
public getDataReader(str eller cmd) osv ...
Men ifall jag vill skapa externa commands måste jag nu veta vilken typ av koppling som DAL använder, vilket inte är önskvärt. Jag skulle vilja skapa t.ex. DataAccessLayer.myCommand som ska fungera exakt som t.ex. odbcCommand eller oledbCommand skulle göra. Samma med parameters.
Hur har andra löst just detta. Kanske man inte behöver skapa egna commands på detta sätt? Några tips och riktlinjer skulle uppskattas.
Det finns Interface för de olika databas objekten som du kan använda. Dessa bör du använda istället. Så istället för att du returnerar OdbcCommand så returnerar du ett IDBCommand istället. Vilket gör att du kan operera på det det objektet utan att veta vilken databas som du har bakom.
Du måste dock skapa rätt objekt i din CreateCommand() metod, så du får helt enkelt skicka med vilken databas som du använder (eller läsa ur det ur din connectionstring) så du skapar rätt Command objekt, men skickar tillbaka Interfacet istället för själva objektet. Typ något sånt här:
public IDBCommand CreateCommand(string connectionString)
{
//-- declare command interface
private IDBCommand _DBCommand = null;
//-- Find out what type of databas used from connectionstring
if(DB == SqlServer)
_DBCommand = new SqlCommand(connectionString);
elseif(DB == Access)
_DBCommand = new OleDbCommand(connectionString);
return _DBCommand;
}
Ok. Har testat bygga om nu och det verkar ju funka. Byter jag mellan oledb och sql i connectionsträngen skiftar dalet automatiskt. Verkar dock inte finnas något färdigt för odbc?
Dessutom fick genomförandet när man skapar commands i BL ändras lite då man nu var tvungen att arbeta med commands innehållandes en färdig connectionstring, vilket jag satte vid själva körningen tidigare.
Anropar nu alltid denna funktion för att skapa commands.
public IDbCommand createCommand() {
return defaultDataConnection.CreateCommand();
}
Fattade att createCommand skapade en ny instans med rätt sorts command beroende på connectionString. Förstod jag det rätt då ditt exempet tog en smått annorlunda approach?
Fattade att createCommand skapade en ny instans med rätt sorts command beroende på connectionString. Förstod jag det rätt då ditt exempet tog en smått annorlunda approach?
Menar du att .NET själv finner ut vilken typ av Command objekt du vill ha utifrån connectionstringen. För det hade jag ingen anning om, min tanke vara att du själv skulle finna denna information i connectionstringen eller skicka med en parameter in till din funktion som berättade vilken databas du tänkte använda dig av.
Dessutom fick genomförandet när man skapar commands i BL ändras lite då man nu var tvungen att arbeta med commands innehållandes en färdig connectionstring, vilket jag satte vid själva körningen tidigare.
connectionsträngen bör skickas in till metoden CreateCommand() och hämtas från applikationens config fil, allt för att det skall vara så enkelt som möjligt att skifta ut connectionsträngen om du bytar databas.
Menar du att .NET själv finner ut vilken typ av Command objekt du vill ha utifrån connectionstringen.
Både ja och nej. Den skapar tydligen en ny instans av ett command som passar den typ av connection man använder (sql eller oledb). Däremot var jag tvungen att läsa av connectionsträngen och själv avgöra vilken typ av connection som ska skapas. Det problemet försvinner om man skickar in en egenskapad connection till DAL att använda vid varje anrop.
Jag har precis som du tipsat lagt connectionsträngen i web.config och istället valt att identifiera connectionsträngen för att skapa rätt connection, vilken sparas privat i dal.
273 ms totalt · 4 externa anrop · v20260731065814-full.a51de22e
