Home/ Questions/Q 9208227
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-18T00:34:18+00:00

My solution is divided as follows: Data project – holds Entity Framework Business Logic/Services

  • 0

My solution is divided as follows:

  • Data project – holds Entity Framework
  • Business Logic/Services project – contains classes that implement business logic/do other work on the data
  • MVC3 project

The way I have this set up is the services class does work involving entity framework. I’m using dependency injection for creating the repository wrapping Entity Framework. The problem I’m running into is that each time the repository is created via ninject, it’s creating a new EF context so not all changes are being saved. Note that I have Ninject bindings in both the services project and the MVC project, and the instance I’m talking about here is when the bindings are located in the class library.

Based on the research I’ve done, it seems to be recommended to use InRequestScope so that way the same context gets used. However, since I’m using this in a class library instead of the MVC project/web project, does it make sense to use Ninject.Web.Common in the class library (where it goes and creates AppStart folders and everything)?

Or is there another way I should handle this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I was misunderstanding how Ninject.Web.Common worked and I was getting confused by the auto-added NinjectWebCommon cs file that was automatically added via nuget install, making me think that it was only for the entry point project. I wasn’t aware that my class library would have access to HttpContext and by getting rid of the AppStart folder that the nuget package “helpfully” added, I was able to use InRequestScope in my class library.

    • 0