Using Entity Framework without a database

[Thes]

Hi all,

I have a small service application which routes incoming queries to any of a number of plugin servers. This list of plugins is determined at runtime and the decision about which to use is determined based on information that the plugins report in response to a ReportAbilities method during startup.

This ability information is all a bit complicated, so I thought I could usethe Entity Framework to populate a model at runtime and then query that.

Is that a reasonable idea given that there will be no database behind it? As far as I can see the Entity Framework _requires_ a database, unless there's some clever workaround I'm just missing.

Ideally, I'd like to define my model, then populate it at runtime so that Ican use it for the lifetime of the application.

Any ideas for this or other approaches much appreciated!
Thanks,
Thes.

 

[Arne Vajhøj]

I have a small service application which routes incoming queries to
any of a number of plugin servers. This list of plugins is determined
at runtime and the decision about which to use is determined based on
information that the plugins report in response to a ReportAbilities
method during startup.

This ability information is all a bit complicated, so I thought I
could use the Entity Framework to populate a model at runtime and
then query that.

Is that a reasonable idea given that there will be no database behind
it? As far as I can see the Entity Framework _requires_ a database,
unless there's some clever workaround I'm just missing.

Ideally, I'd like to define my model, then populate it at runtime so
that I can use it for the lifetime of the application.

Any ideas for this or other approaches much appreciated!

EF is an ORM framework. It is intended to access data that
is relational.

Your plugin data could probably be treated as being relational.
You can write an ADO.NET provider for anything. In practice it
is always for databases, but someone actually once wrote one for
XML. You could certainly write one for your plugins.

But:
1) it would require a lot of code
2) it is difficult to see the real benefits

What you are suggesting is:

LINQ to EF-->EF-->custom ADO.NET provider-->your plugins

I am pretty sure that you can do:

LINQ to Objects-->custom plugin manager that reads into
collection-->your plugins

with a lot less code and get the same query capabilities.

Arne