2

Is there a way to implement dependency injection with Entity framework and lazy loading?

I am aware of method when you are hooking to ObjectStateManagerChanged, but I'd like to use constructor injection instead, and keep my model entities unaware of any IOC containers. (Lets say I have separated BLL and DAL and want to keep my BLL with least external dependencies possible).

Thank you.

Val Bakhtin
  • 1,434
  • 9
  • 11
  • 1
    Prevent from using dependency injection in your entities altogether. Related: http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-objec – Steven May 19 '12 at 16:00
  • I'd agree... but I need to implement configurable security context. Simple example: I'd like to manage access level to model (read/write permissions to certain entitytypes/properties) from external app. – Val Bakhtin May 20 '12 at 00:55
  • 2
    Try using the [command / handler pattern](http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91) for writing business operations. By defining one generic interface, you have great extensibility and the power to implement security checks by implementing a simple decorator. – Steven May 20 '12 at 14:01
  • Thank you. And that is what I am doing for business operations, but with lazy loading, ui developer can go unrestricted to any entity in relational tree. And I need to manage access to properties also. – Val Bakhtin May 20 '12 at 16:34
  • 2
    You can prevent lazy loading and return DTOs. This way you as a BL developer have control over what is returned to the PL and there will be no surprises. – Steven May 20 '12 at 19:30
  • @Steven, post something as your answer, even if it was not exactly what I was looking though, thank you for all your input. They backed my conjectures. – Val Bakhtin May 21 '12 at 14:30

2 Answers2

3

Prevent from using dependency injection in your entities altogether. Take a look at this SO question for instance.

Try using the command / handler pattern for writing business operations. By defining one generic interface, you have great extensibility and the power to implement security checks by implementing a simple decorator.

To prevent UI developers from accessing data they shouldn't be accessing, write one (or multiple) decorators that wrap command handlers (and query handlers) and prevent from returning entities with lazy loading abilities from your business layer. Instead return DTOs. This way the business layer has full control.

Steven
  • 166,672
  • 24
  • 332
  • 435
1

You cannot use constructor injection with EF. EF always use default constructor when materializing entity from database records. The only option you have in this case is using ObjectMaterialized event of ObjectContext and use properties in your entity to pass your initialization data.

You should follow @Steven's comments to implement logic you need.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Thank you for all your comments and advices, They were considered already. Question was on particular combination of technologies - Lazy EF + DI. Anyway I got my answers, even if they are negative. Thank you again. – Val Bakhtin May 21 '12 at 14:26