views:

42

answers:

2

As a follow on from this question I'm building a custom server control to be placed on a Sharepoint 2010 master page.

The idea behind this is that it will display a menu that is dynamically populated from the database.

As this is a server control, I'm building it in a dll but I've run into a small snag. As it has to connect to the database, I need to store the connection string somewhere (and have it able to be configured based on target configuration (dev/test/prod).

I was intending to the user the Entity Framework as my ORM but i'm confused as to where the connection string is to be stored. In a normal ASP.NET web app it goes in the web.config, but this is a server control in a external DLL.

Where do I store the connection string so that I can just build and deploy the assembly containing the server control.

EDIT:
Before I post a bounty, I have tried using an embedded resource XML file to hold the connection string and while this works, I'm curious as to if this is best practice/a better way?

A: 

The connection string should be placed in whatever the application the .dll is in uses for its configuration file. Since this is ASP.NET, the web.config file will do nicely. When you invoke any methods from the DLL, you should pass the connection string to it as an object:

MyConnectionString
{
    get
    {
        return ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString
    }
}

usage:

using(SqlConnection conn = new SqlConnection(MyConnectionString))
{
    //other stuff here. Like making your command object, or passing it.. etc.)
}
George Stocker
So if I add the connection string to the Sharepoint `web.config`, it will pick this up automatically?
Alastair Pitts
@Alastair Pitts It may or may not. I wouldn't bet on it. You'll have to write a line of code that returns the connection string and pass it to the DLL. I've updated my answer to include a possible way of doing it.
George Stocker
+1  A: 

I would recommend against having the control connect to the database. Instead, the user of the control should connect to the database, and then databind to the control.

John Saunders
I'm not sure I understand. How do you mean the user of the control should connect?
Alastair Pitts
Yes. Separation of concerns. A control should be concerned about rendering HTML. Something else should be concerned about passing the data to the control that the control needs to render the HTML.
John Saunders
OK, that's fine, but I can't think of a way that the control would be able to get this information. What would the control call to populate itself (considering I'm just trying to build a control that can be plugged into a Sharepoint page)
Alastair Pitts
It would databind just like a DataGrid does.
John Saunders
Hookay, now I'm pretty confused. What exactly are we databinding to the control? The connection string? or the required data? If it's not clear, I'm using the results of the connection to create some HTML, not to display it in a table or somesuch.
Alastair Pitts
@Alastair Think of how a Repeater, GridView or FormView control works - they don't connect directly to a database they have a DataSource property that allows them to pull in their data from elsewhere (eg. ObjectDataSource control or an IEnumerable collection).
Dan Diplo
@Alastair: it's as Dan suggests. The control should only display HTML based on the data it is given. It should never _get_ data, never _take_ data, it should be _given_ the data.
John Saunders
OK, I think I understand now. I need to use an SQLDataSource control to connect to the DB, then bind that result to a property on my custom control, which then renders it? (As you might have noticed, I've barely used WinForms controls)
Alastair Pitts
@Alaistair: Yes, that's correct. This way, your control will not be dependent on the details of your data source. Any data source with the same "shape" will work.
John Saunders
@John: Thanks for your help. It's taking a fair bit of a head shift, but I think I'm getting the idea.
Alastair Pitts