>Hi,
>
>I'm using the MM.NET 4.1 beta, but I think this applies to 4.0 as well.
>
>I created a new "test" application and started playing with entity framework. (I hadn't touched EF before.) Now I'm encountering some confusion over the database connection properties in app.config. Namely the "key" element in the databases tag, versus the "name" element in the connectionStrings tag for Entity Framework.
>
>Historically, the DatabaseKey property in ABusinessObject would contain a value from the databases tag which has been my ticket to the database connection. But now with Entity Framework, it looks like that same DatabaseKey property in ABusinessObject must now use the connectionStrings value in order to run. Do I understand that correctly? If so... then that raises some new questions.
>
>1) Is the databases tag in app.config irrelevant if the app will use Entity Framework?
>
>2) Is Entity Framework just a design-time thing? I thought it was. But that connectionString is full of EF information. If I need that at runtime, does my shipping application contain all that model information in the compiled assemblies? I'm confused at what EF is/does at runtime.

I'm not very familiar with MM so will concentrate on trying to answer just this part. The IDE designer for the Entity Framework essentially produces a file containing three XML sections (you can view these by choosing an XML editor rather than the default visual designer when opening an edmx file in fhe IDE).
The three sections define
(a) the 'Storage Model' which describes the underlying datasource (in your case that seems to be an SQL database?)
(b) the 'Conceptual Model' which describes the objects which will be used.
(c) a 'Mappings' section detailing how (a) and (b) are wired together.

This information from these sections is (normally) compiled into the containing assembly.

The Entity Framework 'connection string' created by the EDMX wizard in the app.config is not a simple ADO.NET type connection string but consists of several parts - the last of which is the standard SQL connection string. The earlier parts point to the three sections mentioned above which are stored as resources within the assembly.

When you instantiate the EF ObjectContext with no parameters it will use the information from the app.config but there are constructor overloads which accept either an alternative (EF type) connection string or an already instantiated EntityConnection.

Don't know whether any of the above will help you in determining how all this works viz a viz MM.NET though.....


>3) The MM.NET wizard created a connectionString with a name value of "EntityDataModelContainer." Should I be giving thought to a more real-world naming convention since this (might?) have meaning at runtime? Or is this generic name totally fine... and won't bite me in the ass later on -- in a real world application to be installed in production environments?
>
>Thanks,
>Guy