1

I want to run a LINQ statement on a DBSet of EntityFramework. Since I use a different type of objects (Not the type of my entities) in my application, I need to mutate the expression so it will contain EntityFramework objects and not my application objects.

I used the answer in this question to do so: Mutating the expression tree of a predicate to target another type

But I can't find out how to actually use the result...(as a Predicate or a Func, etc) I've seen that there once was a Compile method in Expression, but it's not there any more.

Can somebody explain to me how to do this?

EDIT:

I'd like to use an interface such as this:

public interface ICRUDFacade<T>
{
    bool Create(T source);

    IEnumerable<T> Read(Predicate<T> exp);

    bool Update(T source);

    bool Delete(T source);
}

and in the implementation of the EntityFramework facade convert T to an object that can be inserted into a DbSet. When I run the LINQ expression in the Read method I will receive Entity objects and then convert them back to T

Community
  • 1
  • 1
Idov
  • 5,006
  • 17
  • 69
  • 106
  • 1
    I don't understand what you mean by "not my application objects". Entity Framework uses proxy types derived from your POCOs. Could you provide a code example? – Asad Saeeduddin Sep 17 '15 at 18:03
  • Can you be more concrete? You will need to execute the expression as a query and then translate the materialized objects back. Also note, that what you are doing is 90% certain to be an anti-pattern. – usr Sep 17 '15 at 18:08
  • I have the objects that EntityFramework uses and I can get from the DbSet. In order to separate my application from EntityFramework, I use interfaces so I don't care which kind of SQL queries framework I use. I can have a DogEntity that EntityFramework will know and a DogObject that I can convert from an to this entity and use anywhere else. – Idov Sep 17 '15 at 18:08
  • @usr: How else can I separate the queries framework from my application. I may want to replace it one day and I'd like it to not affect other parts... – Idov Sep 17 '15 at 18:10
  • The way you replace EF is by branching in your source control tool, replacing it and merge back. – usr Sep 17 '15 at 18:12
  • I think you need to post code. I don't know how anyone could give a useful answer right now. – usr Sep 17 '15 at 18:13
  • It seems like you are concerned about creating a tight coupling with EF, but instead of your current approach, why not just add a proxy class (with an interface) and have that class interact with EF? – 1.618 Sep 17 '15 at 18:14
  • @1.618: I thought about this, but I'd like my "application objects" to be immutable. I can't be certain that they are if I use interfaces :/ – Idov Sep 17 '15 at 18:17
  • 1
    I totally have no idea about what this question is about. If you want an answer, update your question with some concrete problem, simple enough to describe why and how it is a problem. I guess code may be required - and although it may be just a method signature - but it's important. – Hopeless Sep 17 '15 at 18:22
  • IMO, you're _way_ overcomplicating things by making your interface a generic. – 1.618 Sep 17 '15 at 18:26
  • `there once was a Compile method in Expression` - only `LambdaExpression` has Compile method. So you may need to cast it to some known LambdaExpression before being able to use Compile. – Hopeless Sep 17 '15 at 18:28
  • 1
    `IEnumerable Read(Predicate exp);` is the problem in your design. It can be implemented, but would require you to load the whole entity set and then do the filtering. You really need to change `Predicate` to be an expression (either `Expression>` or `Expression>` would work, the later is considered more standard) in order to be able to convert and use it as `DbSet` predicate. – Ivan Stoev Sep 17 '15 at 19:12
  • If you want your "application objects to be immutable" (I hope I'm not misunderstanding you), you should use a document oriented database. The client libraries for those are very well equipped for instantiating your immutable objects from their constructor, and use no reflection/proxy black magic to try and track what's going on with instances. Once the client retrieves some data and instantiates the documents, that's it; they're just normal instances of your "application objects". No ORM tentacles inside their guts, like in EF. – Asad Saeeduddin Sep 18 '15 at 06:17

0 Answers0