I'm doing some prototyping / learning to use EF to create DTO's for my business objects ...
just did a quick search here and it looks like I might be on the bleeding edge ... no documentation from anyone who has dealt with the challenge (connection string info not being passed to ORM in teir-ed architecture ). I want to implement:
I'm into day 2 on this and keep running into connection string resolution problems when in development mode ....
I did see a blog post with a sample of how to pass the connection strings in code to the Data Context ... will be trying that but am not overly optimistic.
Can anyone point me to a "best practice" from experience ??
I'm assuming that I should be aiming for a solution where there is not a need for multiple app configs with the same connection strings ... something that is complicated by the fact that the connection string in EF is a combination of the SQL connection and the path to some of the EF metadata schema.
Sharing a fix for this will be greatly appreciated.
Steve
ok ... unless there's someone who has mastered this and can give me a simple cook book approach ... per this:
it looks like ... during development ... I'm going to need to put the connection string in every assembly "that consumes" an EF object .....
So I guess we can raise the discussion to the architecture level here ... the main reason I am going with entities and LINQ is to be able to do joins and poplulate BO's with data from multiple services ... and possibly heterogenous platforms on the back-end (talking to my "Model" layer ) ... some XML DTO's others ADO EF objects
I would like to wrap my head around how this can fit into an architecture where databases and services are on different machines .... both in my domain where I can go with NamedPipes and in othere scenarios where I will be consuming via HTTP ... REST-FUL of course .... and then there is Azure ....
.... and of course whether it makes sense to follow / how to implement using CSLA's Object In Control function.
Clearly my goal here is to do a lot of integration and mashing-up .... a performance nightmare ???
thx,
Steve
I
am not sure I follow the issue. I only have connection strings in two
spots: app.config in EF project (contains EF models only) and in web.config in
the csla WCF server project. I always copy one into another. It
does help if all developer machines are the same though, so none has to change
a connection string. If they do, they will have those config files
checked out all the time.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: mondoh
[mailto:cslanet@lhotka.net]
Sent: Thursday, December 03, 2009 12:32 PM
To: Sergey Barskiy
Subject: [CSLA .NET] help !! entity framework / connection string(s) for
tier-ed deployment
I'm doing some prototyping / learning to use EF to create DTO's
for my business objects ...
just did a quick search here and it looks like I might be on the bleeding
edge ... no documentation from anyone who has dealt with the
challenge (connection string info not being passed to ORM in teir-ed
architecture ). I want to implement:
I'm into day 2 on this and keep running into connection string resolution
problems when in development mode ....
I did see a blog post with a sample of how to pass the connection strings in
code to the Data Context ... will be trying that but am not overly optimistic.
Can anyone point me to a "best practice" from experience ??
I'm assuming that I should be aiming for a solution where there is not
a need for multiple app configs with the same connection strings ... something
that is complicated by the fact that the connection string in EF is a
combination of the SQL connection and the path to some of the EF metadata
schema.
Sharing a fix for this will be greatly appreciated.
Steve
I'm puzzled as well.
The EF designer maintains a connection string for convenience during development - and that's not in the config file.
But in production the connection string should come from your config file, and there's only one config file per app ever - either web.config on a server, or myprogram.exe.config (app.config) on a smart client.
If you really don't want to use a config file for some reason you'll be fighting .NET all over the place. But you can do it by creating an assembly with a static class that has a static read-only property that returns the connection string - then use that global property value every time you create an object context. Not a great solution, but .NET is designed around the use of config files...
Copyright (c) Marimer LLC