Naor
Naor

Reputation: 24093

expose Include method

I have an interfaces for my data tier that supply common methods like insert, update, delete, getQuery.

Sometimes I want to add a method that handles the repository. I noticed that I can do almost everything using those common method that the interface supply. The only thing I cannot do is "Include".

I have doubts whether to add the Include method to the db interfaces so my business tier can do everything without being depend on the entity framework (system.data.entities).

What is the workaround for this problem?

Upvotes: 2

Views: 152

Answers (2)

Ladislav Mrnka
Ladislav Mrnka

Reputation: 364319

Exposing custom Include wrapper will not make your upper layers dependent on EF. Include will became part of your DAL layer public interface. Making decisions like "what if I decide to change ORM?" is really bad way to make your application - build working solution and then improve it if you have time do it. Switching to other ORM is really rare and planning your application to support that switch is in 99% cases waste of time and waste of money. Your responsibility is to deliver working solution in time not extensible solution three months later.

The only disadvantage with exposed Include can be unit testing and mocking - this requires hiding EF related Includes to DAL internals so that it can be mocked. That is probably solved in your previous question.

Upvotes: 3

Adam Rackis
Adam Rackis

Reputation: 83356

There's not really a workaround. Adding Include to your DB interfaces (IObjectSet) is a common approach to solving this problem. As far as your concern about being tied too closely to Entity Framework, well, I'd say that switching ORMs completely down the road will be quite a bit of work regardless whether you add this extension method. I wouldn't worry about it.

Here's a blog post from Julie Lerman on adding the Include extension method

Upvotes: 1

Related Questions