Wo sollte in einem mehrschichtigen Design mit einer separaten DataAccess-Schicht in .NET die Verbindungszeichenfolge verwaltet werden?

Question

Es gibt eine lange laufende Gewohnheit hier, wo ich arbeite, dass die Verbindungszeichenfolge in der web.config lebt, ein Sql-Verbindungsobjekt in einem using-Block mit dieser Verbindungszeichenfolge instanziiert und an den DataObjects-Konstruktor übergeben wird (über eine CreateInstance-Methode, da der Konstruktor privat ist). Etwa so:

using(SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString))
{
    DataObject foo = DataObject.CreateInstance(conn);
    foo.someProperty = "some value";
    foo.Insert();
}

Das alles riecht für mich Ich weiß es nicht. Sollte nicht die DataLayer-Klassenbibliothek für Connection-Objekte und Connection-Strings zuständig sein? Ich wäre dankbar zu wissen, was andere tun oder gute Online-Artikel über diese Art von Design-Entscheidungen.

Bedenken Sie, dass die Projekte, an denen wir arbeiten, immer Sql Server-Backends sind, und es ist äußerst unwahrscheinlich, dass sich das ändert. Das Factory- und Provider-Muster ist also nicht das, wonach ich suche. Es geht eher darum, wo die Verantwortung liegt und wo die Konfigurationseinstellungen für den Betrieb der Datenschicht verwaltet werden sollten.

Answer 1

Ich kodiere die Klassen in meiner Datenzugriffsschicht gerne so, dass sie einen Konstruktor haben, der eine IDbConnection als Parameter annimmt, und einen anderen, der eine (Verbindungs-)Zeichenfolge annimmt.

Auf diese Weise kann der aufrufende Code entweder eine eigene SqlConnection erstellen und diese übergeben (praktisch für Integrationstests), eine IDbConnection nachbilden und diese übergeben (praktisch für Unit-Tests) oder eine Verbindungszeichenfolge aus einer Konfigurationsdatei (z. B. web.config) lesen und diese übergeben.

Answer 2

Hm, ich denke, ich stimme zu, dass die Datenschicht für die Verwaltung solcher Verbindungszeichenfolgen verantwortlich sein sollte, so dass sich die höheren Schichten nicht darum kümmern müssen. Allerdings glaube ich nicht, dass die SQLConnection sich darum kümmern sollte, woher der Verbindungsstring kommt.

Ich denke, ich würde eine Datenschicht haben, die bestimmte DataInputs bereitstellt, d.h. Dinge, die eine Bedingung annehmen und DataObjects zurückgeben. Solch ein DataInput weiß nun "Hey, diese DataObjects sind in DIESER Datenbank gespeichert, und mit Hilfe der Konfigurationen kann ich einen Verbindungsstring verwenden, um eine SQL-Verbindung von dort zu erhalten.

Auf diese Weise haben Sie den gesamten Prozess "Wie und woher kommen die Datenobjekte?" gekapselt, und die Interna der Datenschicht können weiterhin ordnungsgemäß getestet werden. (Und, als Nebeneffekt, können Sie problemlos verschiedene Datenbanken oder sogar mehrere verschiedene Datenbanken gleichzeitig verwenden. Eine solche Flexibilität, die einfach auftaucht, ist ein gutes Zeichen(tm))

Answer 3

Dies ist ein "Geruch" ist relativ. wenn Sie ziemlich sicher über die Kopplung dieses bestimmten Stück Code zu SQL Server und eine web.config Verbindungszeichenfolge Eintrag dann ist es völlig OK. wenn Sie nicht in diese Art der Kopplung sind, stimme ich, dass es ein Code Geruch ist und unerwünscht ist.