c# - Where is the proper place to add a method to handle SQL Connection String in ASP.NET WebAPI -

i have set of many databases follow same schema , i've abstracted pertinent tables in model layer of application. i'm using sqlconnections handle connecting database , data adapters , data tables store , move information , through controllers etc. code below using, working fine now:

using (sqlconnection con =         new sqlconnection(     "server=myserversip\\nameofinstance; " +     "initial catalog=thisisvariable;" +     "user id=username;" +     "password=password123;")) { /* stuff happening here */ } 

what using more here:

using (sqlconnection con =         new sqlconnection(getconnectionstring("databaseidentifier"))      {          /* stuff  still happening here */      } 

so i'm looking right place put method:

public string getconnectionstring(string databaseidentifier) {      string theconnectionstringineed = "appropriateconnectionstring"     return theconnectionstringineed;  } 

i new mvc , web api in terms of structure etc, , want make sure i'm following best practices.

my question in standard structure should such method go? want accessible wherever in hopes of keeping whole connection string process dry, need dynamic (definite output based on database identifier input)

it seems simple enough question, can find after dedicated searching examples on how use entity framework or folks generating databases model, etc, not using connection strings.

please advise, , thank community.

this meant answer more general question of "my question in standard structure should such method go? " , expands on little architectural thoughts...

not sure if you're doing so, though put database tasks - in crud , connection stuff - project of it's own - data access layer in case.. keep project separate models. - kind of directly answers initial question "where should go..."

you can add reference model layer. (assuming have models in project on own)

this keeps 2 separate. why? well, 1 day might decide use entity framework, or other means of communicating database. if that's case need change data access layer. , can keep models looking shiny , new still.

if want push boat out create project sits between web site , the, new, data access layer - call services. middleman between database , website.

you call middleman service website controllers. middleman service runs off data access layer. layer goes database, gets data, populates models , gives them middleman. middleman applies business logic related site , transforms data models things view models (skinny versions of models website view you're showing) - has advantage of not sending big complex objects views rendering. keeps business logic (which more not related directly project calling middleman) out of data access , model layers.

now things nicely broken , can switch bits , bobs out requirements change.

so, in total laymen term.. workflow this:

• user clicks link

• web site controller gets hit go fetch data...

• controller asks service middleman data, controller wants little bit of it, asks small version (viewmodel)

• service middleman says 'ok, gimme sec..'

• service middleman runs on data access layer , says 'gimme data' , asks full blown model (a row db)

• the middleman gets data access layer , says 'hmm..the controller said didn't need half of these properties..' middleman creates instance of viewmodel (that defined, model).

• the middleman populates instance, view model, data model data access layer gave it.

• the middleman might other stuff, businessy-logic stuff..

• he hands controller , says 'there go govn'er '

• the controller returns in action result.

and there fun lil way explain :d

a little side note

you mentioned people seem create database models - called code first. can database first - sounds..

i would, this, recommend entity framework powertools. has awesome reverse-engineer tool build of models & relationships db. freakin awesome!