Question

假设这样的架构。

MODEL > BLL > DLL

尝试在我的模型中实现延迟加载我遇到了我的MODEL和BLL之间的循环依赖..

基本上想象我想要实现的模型中的属性如下

Public Readonly Property ProjectCategory As ProjectCategory
    Get
        If Me._ProjectCategory Is Nothing Then
            Me._ProjectCategory = ProjectCategoryBLL.GetProjectCategoryByID(Me._ProjectCategoryID)
        End If

        Return Me._ProjectCategory
    End Get
End Property

我将MODEL，BLL和DLL放在不同的项目中，因为我的BLL引用了我的模型，我不能从模型中引用我的BLL，因为这会创建循环依赖。

这个问题的典型解决方案是什么？

Answer 1

看起来你的事情非常混乱，很可能是由于对层级和模式的理解混乱。

为什么您的BLL会参考您的模型？它应该没有必要。在经典的n层应用程序中，模型和BLL是同一个东西。如果你然后去为你的UI（比如MVVM）实现模式，那么模型可能仍然是BLL，或者它可能是调用BLL的单独代码（并且BLL没有直接的模型知识）。在MVC中，模型处理数据，因此它再次与BLL对话（或者甚至可以集成并且是BLL的一部分）。

我的建议是模型引用BLL，但不是相反。或者您可以将模型集成到BLL中，具体取决于您正在构建的复杂程度。

Answer 2

您可以为Model项目中引用的bll类创建接口，并使用工厂模式或使用依赖项注入创建具体类。只是准备为您的项目增加一些复杂性。替代方案可能是看看ORM。它们会处理很多延迟加载的属性，看起来你正试图实现

Answer 3

我不赞成您当前的架构。当然，将应用程序分层为逻辑层或物理层依赖于您的项目需求和复杂性。但是最好摆脱当前的实现并应用新的架构：

域模型：由您的域实体，存储库的接口等组成。
存储库：实现域模型中定义的存储库合同，您可以拥有不同的存储库实现。
AppService ：由View Models，Messages，Application Services等组成。这将是用户进入整个系统的切入点。
演示文稿：会实现类似MVP或MVC模式的演示模式。

这将是分层应用程序的通用架构。尝试针对接口而不是具体实现进行编程。此外，您提取业务组件（应用程序层）的次数越多，并且越多地利用Design Patterns和最佳实践的优势，您就确保您的代码库更具可伸缩性，松散耦合性和更好的可维护性。

如果您正在开发产品而不仅仅是自己的示例应用，我建议您更深入地了解Domain-Driven Design，Enterprise Application Architectures和Design Patterns以便能够建模您的业务需求更好，并实现更好，更强大的架构。

如果您需要更多信息或具体问题，我们很乐意多谈这个问题[：

MODEL和BLL之间的循环依赖

3 个答案: