All geek questions in one place

In a layered design with a separate DataAccess layer in .NET, where should the connection string be managed?

There is a long habit here, where I work on the fact that the connection string lives in web.config, the Sql Connection object is created in the using block with this connection string and passed to the DataObjects constructor (using the CreateInstance method as the constructor is private). Something like that:

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

All this smells to me .. I don't know. Should the DataLayer class library be responsible for Connection objects and Connection strings? I would appreciate it to find out what others, or any good online articles about these design decisions are doing.

Please note that the projects we are working on are always Sql Servers, and this is unlikely to change. Thus, the factory and provider template are not what I need. It is more about where responsibility lies and where configuration parameters must be managed to work at the data level.

+3
source share
3 answers

I like to code classes at my data access level, so they have one constructor that accepts IDbConnection as a parameter and the other a string (connection).

, SqlConnection, ( ), IDbConnection ( ) (, web.config) .

+4

, , datalayer , . , , SQLConnection , .

, datalayer, DataInputs, , DataObjects. DataInput : ", DataObjects THAT, , , SQL-.

, " "? datalayer . (, , . , , (tm))

+1

this "smell" is relative. if you are sure that you will associate this particular piece of code with SQL Server and the connection string string web.config, then this is completely normal. if you do not participate in such a connection, I agree that this is a smell of code and is undesirable.

0
source

Source: https://habr.com/ru/post/1698026/

More articles:


All Articles