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开发者_StackOverflow中文版 my business tier can do everything without being depend on the entity framework (system.data.entities).
What is the workaround for this problem?
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.
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
精彩评论