2

How do I specify Xml or just in-memory storge for Entity Framework models? The connection string requires a provider (usually a SQL provider string). But it won't let me omit the provider.

I realize I could completely throw away the designer generated objects and go pure POCO, but then I'd have to implement my own serialization layer (could do that, but it's overkill for the tiny project I'm working on).

Is there built-in support in EF 4.0 for this that I'm missing or do I just need to go the pure POCO route and discard the designer experience entirely :(

Simon Gillbee
  • 3,932
  • 4
  • 35
  • 48
  • I'd really like to do this as well, but haven't seen a clean way yet. work with an in-memory context, and then when needed, write evetything out to a data file. For use with a thick client app that uses "files" to save and reload data, and where a db is way overkill. – Brady Moritz Jun 02 '12 at 20:20

2 Answers2

1

If you want to store data in Xml or memory you should probably not use EF. EF is designed to work with relational databases.

See also: Entity Framework with XML Files

For storing data in memory use System.Runtime.Caching

For storing data in xml files see: http://msdotnetsupport.blogspot.com/2007/04/reading-and-writing-xml-files-using-c.html

Community
  • 1
  • 1
Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252
  • In my case the conceptual model is always relational, but the backend storage may or may not be relational. Depending on the specific implementation or connection, it may be SQL, it may be Xml, it may be a custom flat file, or it may be just a temporary collection of objects in memory. – Simon Gillbee Oct 26 '10 at 16:11
  • Thanks for the links... I'll look over them. – Simon Gillbee Oct 26 '10 at 16:13
  • After going down this road for a while, I think you're correct... EF is not a good fit. Thanks for the advice. – Simon Gillbee Dec 13 '10 at 23:15
  • I'd like to know what might be a suitale replacement? Im so tired of using datasets for this... – Brady Moritz Jun 02 '12 at 20:18
0

This is a good way to do what you're probably thinking.

Use a SQLite db as the backing store. That way you get you're single local file and you can still use almost all of EF.

http://dotnet.dzone.com/news/sqlite-entity-framework-4

majinnaibu
  • 2,832
  • 1
  • 18
  • 22