MODEL和BLL之间的循环依赖

Question

假设这样的架构。

MODEL > BLL > DLL

尝试在我的模型中实现延迟加载我遇到了模型和 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 类创建接口，并使用工厂模式或使用依赖注入创建具体类。准备好为您的项目增加一些复杂性。另一种方法可能是看一下 ORM。他们会处理很多看起来你正在尝试实现的属性的延迟加载

Answer 2

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

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

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

如果您正在开发产品而不仅仅是为您自己的示例应用程序，我建议您更深入地研究Domain-Driven Design、Enterprise Application Architectures 和Design Patterns，以便能够更好地模拟您的业务需求并实施更好、更健壮的架构。

如果您需要更多信息或具体问题，我们很乐意就此进行更多讨论 [:

Answer 3

看起来你把事情搞混了，很可能是由于对层级和模式的理解混淆了。

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

我的建议是让模型引用 BLL，而不是反过来。或者，您可以将模型集成到 BLL 中，具体取决于您所构建内容的复杂性。