我有一个应用程序，它被分成4层，以保持代码的组织并能够重用它。
我的图层是：
所以我的想法是，对于每个控制器或我们的mvc项目，我们有1个业务类和1个数据类。如果某些功能需要在其他类上使用代码，则它们在业务逻辑层执行（不同的业务逻辑类可以创建其他业务逻辑类的新实例。）
我遇到的问题是我创建的DbContext太多了，因此我遇到了一些错误和问题。就像丢失BL层上的延迟加载一样，或者当它们来自不同的DbContext时，无法将列表之类的对象分配给其他对象。
例如，如果我有医疗控制器/逻辑/数据并且我使用患者逻辑/数据来获取今天的患者列表，那么当我尝试medic.patients = patienstList;
所以我需要做的是每个Web请求使用一个DbContext，因此将在控制器上创建DbContext并注入逻辑层，这些将注入其他逻辑类或者数据类？
我该怎么做？
答案 0 :(得分：0)
在MVC中有很多方法可以做IOC。 示例将Unity ..您可以在其中注册DBContext的实例。
当然，如果您的IOC容器的生命周期都延伸到Web请求之外。你是在讨厌的时候。 即使您认为每个请求需要1个上下文。如果使用ASP管道事件并访问DbContext，请务必小心，实际上每个线程可能需要1个上下文。但是，如果您乐意说您从MVC控制器级别开始访问。那么你正在寻找一种只处理控制反转的方法。
答案 1 :(得分：0)
恕我直言，业务对象不应该使用其他业务对象，因为这违反了单一责任原则。
数据层对象应该能够执行业务对象所需的所有内容。
因此，您应该在业务层对象和数据层对象方法GetPatientsForMedic中编写方法。
你可以说＆＃34;但是医院商业对象可以很容易地给我一份医院名单＆＃34;。这不是它的工作，因为你说它的工作是服务于医院的控制者。
但是，只有将医院对象从HospitalsBO传递给MedicBO时才会出现问题。所以不要。
在Hospitals控制器上，编写方法GetListOfHospitalIDsAndNames。然后，如果您需要下拉医院，请拨打该医院，并使用ID和文本名称。
您确实可以通过共享工作单元在两个Business Objects之间共享DbContext。但你可能不应该这样做。
但是，我没有专家......我通过让一个GINORMOUS业务对象包含其中的所有内容来避免这些问题。这也是一件坏事。