Circular dependency between MODEL and BLL

Assuming an architecture as such.

MODEL > BLL > DLL

Trying to implement lazy loading in my MODEL I have run into a circular dependency between my MODEL and BLL..

Basically imagine a property in my model that I want to implement as follows

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

I have my MODEL, BLL and DLL in separate projects and because of the fact that my BLL references my model I can not reference my BLL from my model as this would crea开发者_JAVA百科te a circular dependency.

What is the typical solution to this problem?

---

It looks like you have got things horribly mixed up, most likely due to a mixed up understanding of tiers and patterns.

Why does your BLL reference your model? It should have no need to. In a classical n-tier application, the model and the BLL are one and the same thing. If you then go and implement a pattern for your UI (like MVVM), then the model may still be the BLL, or it may be a separate bit of code that calls the BLL (and the BLL has no direct knowledge of the model). In MVC, the model handles the data, so once again it talks to the BLL (or may even be integrated and part of the BLL).

My suggestion is for the model to reference the BLL, but not the other way round. Or you could integrate the model into the BLL, depending on the complexity of what you are building.

---

I don't approve your current architecture. of course layering your application into logical or physical tiers depend on your project needs and complexity. but it would be a better idea to get rid of your current implementation and apply a new architecture as such :

• Domain Model: consists of your domain entities, interfaces for your repositories, etc.
• Repository: implements the repository contracts defined in the domain model, you could have different implementations of repositories.
• AppService: consists of View Models, Messages, Application Services and so on. this would be the entry point for users into the whole system.
• Presentation: would implement a presentation pattern like the MVP or MVC pattern.

This would be a common architecture for layered applications. try to program against interfaces rather than concrete implementations. also, the more you abstract your business components (application tiers) and the more you leverage the advantages of using Design Patterns and best practices, you make sure that your code base will be more scalable, loosely coupled, and better maintainable.

If you're developing a product and not just sample app for you own, I'd suggest digging a little deeper into Domain-Driven Design, Enterprise Application Architectures and Design Patterns to be able to model your business needs better and implement a better and more robust architecture.

Would be glad to talk more about this if you needed more info or specific questions [:

---

You could create interfaces for your bll classes that are referenced in your Model project and either create a concrete class using the factory pattern or using dependency injection. Just be prepared to add some complexity to your projects. The alternative could be to take a look at ORMs. They take care of a lot of the lazy loading of properties that it looks like you are trying to achieve