The direct answer: use a property if theres only ever one db for your app, a method if you have multiple dbs.
The better solution is to only ever create connections in one place in your application. So rather than having a GetConnectionString() method, you'd have a GetConnection() method. Personally I skip connections too and have an abstraction layer on top of that. I cant discribe the joy of never, ever, having to construct parameters, set db timeouts, manually set the command type or really worry about managing ado stuff.
public class DbParameter
{
public string Name {get; set;}
public object Value {get; set;}
public DbType Type {get;set;}
}
public interface IDbManager : IDisposable
{
DataSet Exec(string procName, params DbParameter[] args);
DataSet ExecDynamicSql(string sql, params DbParameter[] args);
object Scalar(string procName, params DbParameter[] args);
object ScalarDynamicSql(string sql, params DbParameter[] args);
void NonQuery(string procName, params DbParameter[] args);
void NonQueryDynamicSql(string sql, params DbParameter[] args);
} Then on top of that, I have a factory and a few extension methods which use the anonymous objects as dictionaries approach from Asp.Net MVC.
so I end up with something like:
using(IDbManager db = DbManagerFactory.GetDb())
{
DataSet ds = db.Exec("myproc", new {MyobjectsId= 12345});
} as opposed to something like:
Create a connection
Create a Command
set the command text
set the command type
create a parameter
set the parameter's name, value and data type
add the parameter to the command's parameter collection
create a data adapter
set the data adapter's command & connection
create a dataset
use the data adapter to fill that data set