模型和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

我在不同的项目中有我的模型，BLL和DLL，因为我的BLL引用了我的模型，所以我不能从我的模型引用我的BLL，因为这会产生循环依赖。

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

Answer 1

看起来你把事情弄得乱七八糟，很可能是因为混淆了对层和模式的理解。

为什么你的BLL引用你的模型？它应该没有必要这样做。在经典的n层应用程序中，模型和BLL是一回事。如果您随后为您的UI实现了一个模式(如MVVM)，那么模型可能仍然是BLL，或者它可能是调用BLL的一小部分代码(而BLL对模型没有直接了解)。在MVC中，模型处理数据，因此它再次与BLL对话(或者甚至可以集成到BLL中)。

我的建议是让模型参考BLL，而不是反过来。或者，您可以将模型集成到BLL中，这取决于您正在构建的内容的复杂性。

Answer 2

您可以为Model项目中引用的bll类创建接口，并使用工厂模式或依赖项注入创建一个具体的类。准备好给你的项目增加一些复杂性吧。另一种选择是看看ORMs。它们负责大量的延迟加载属性，这些属性看起来像是您正在尝试实现的

Answer 3

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

• Domain模型契约:由您的域实体、存储库接口组成，etc.
• Repository：实现了域模型中定义的存储库契约，您可以拥有由View Models、Messages、Application Services等组成的repositories.
• AppService：的不同实现。这将是用户进入整个system.
• Presentation：的入口点，它将实现类似MVP或MVC模式的表示模式。

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

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

如果您需要更多信息或具体问题，我很乐意与您详细讨论[：