It's not supposed to be easy. One objective of frameworks like EF and DevForce is to insulate you from direct database access. If people start hacking away at the database directly, the app goes sideways fast.
We're also supporting n-tier scenarios which means that the connection strings shouldn't be knowable on the client. Your approach will fail misearably if run on the client in an n-tier deployment (e.g., Silverlight) ... as will mine and as should everyone's. If you could find the connection string from the client, that would be a really bad security violation!
Assuming you are running 2-tier or are performing your operation on the server, we know that you may have to get to the database directly. And so you can.
Take a look at the NumericIdGenerator code sample which uses raw ADO to talk to a table of counters for generating entity ids. After install on my Windows 7 machine it is located here
C:\Users\Public\Documents\DevForce\Learning Resources\040_BusObjPersistence\AddingDeleting\Snippets\NumericIdGenerator
You'd go this route if you were creating entity ids old school with a NextId table in your database instead of using autoincrement columns or Guids.
Work your way quickly to the "AllocateMoreIds" method which takes a DateSourceKey. Inside it acquires an AdoHelper which is an easier way to talk to your database than raw ADO. Oh sure you can get the connection string from AdoHelper if you want.
I'm not saying it's pretty. But it does the job as IdeaBlade thinks you should approach it :-)
======
As you read the code you see that it creates an AdoHelper via a DataSourceKey and that has to be an Ideablade.Ado.RdbKey. DevForce supplies that key to the IdGenerator. You're going to need to get your own.
RdbKeys don't fall off the tree. In fact, you have to construct yours from an EdmKey.
An EdmKey, "Entity Data Model Key", describes a data source that you've modeled. In theory that source does not have to be a database. Of course it usually is and for the rest of this example we will assume that it is.
How do you get an EdmKey? There are lots of ways. The way you did it with the DataSourceKeyResolver works. It just isn't obvious how it works.
I think many will find it more obvious to start with name of the key you want.
If you want to play along, remember to reference the little-used IdeaBlade.Ado and IdeaBlade.Edm assemblies; they are in the GAC and in the IdeaBlade assemblies folder like all the others.
Getting the EdmKey name
You're golden if you know the name brute force. The default name from our Object Mapper is "Default" so you could write:
var edmKeyName = "Default";
If you aren't sure of the name but you know there is only one in your application try
var edmKeyName = IdeaBlade.Core.IdeaBladeConfig.Instance.EdmKeys[0].Name;
That fishes the name from your in-memory IdeaBlade application configuration which is most likely derived from the XML in your app.config (or web.config in n-tier).
If you have multiple EDM models (really? I want to meet you!) requiring multiple keys, then you have to know which EdmKey to use. If you happen to know an entity type that is mapped to the database you want, you can get the name from the type.
var edmKeyName = IdeaBlade.EntityModel.EntityMetadata.GetDataSourceKeyName(typeof(myEntityType));
If you are using DataSourceKeyExtensions ... stop where you are and tell me. You have to toss in a wrinkle at this point in the recipe ... and I don't want to lose any more readers.
Get the EdmKey
Now that you know the edmKeyName, you can get an EdmKey.
var edmKey = IdeaBlade.EntityModel.Edm.EdmKey.LocateEdmKey(edmKeyName);
You're almost there!
You need an RdbKey ("Relational Database Key"). Remember that an EdmKey doesn't necessarily point to a database. You're going to have to ask it to make an RdbKey for you if it can. It will if it refers to a database; it won't if it can't.
Ok ... if all you want is the database connection string, you can stop right now and get it from the edmKey. You found this out already. The phrase is "edmKey.DbConnectionString".
But I want you to consider using AdoHelper. So we will proceed to manufacture an RdbKey like so:
var rdbKey = edmKey.RdbKey as IdeaBlade.Ado.RdbKey;
Now you can write:
var adoHelper = new IdeaBlade.Ado.AdoHelper(rdbKey);
===
Why is this "really ugly" as you say?
I half explained at the top of this post but it bears repeating. The point of using infrastructure like DevForce and EntityFramework (and all of the others) is to decouple your application from the database.
We make it possible for you to have one object model that is built from multiple datasources, some of them databases and some of them not. We make it possible for you to specify and dynamically swap database instances for different environments (dev / test / stage / production) or for multiple tenant applications or because one instance of your application will run against SQL Server and another against DB2 or Oracle ...
... and you don't have to change your code.
IF you start programming in a database-specific way, all our attempts at decoupling are for naught.
When you have to reach the database directly, you certainly can. It just takes some effort to defeat the decoupling that usually works in your favor.
I hope that both answers your question and explains why it seems so baroque.