Круговая зависимость между 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

У меня есть МОДЕЛЬ, BLL и DLL в отдельных проектах, и из-за того, что мой BLL ссылается на мою модель, я не могу ссылаться на мой BLL из моей модели, поскольку это создаст циклическую зависимость.

Какое типичное решение этой проблемы?

Answer 1

Похоже, у вас все ужасно перепутано, скорее всего, из-за смешанного понимания уровней и шаблонов.

Почему ваш BLL ссылается на вашу модель? Это не должно быть необходимости. В классическом n-уровневом приложении модель и BLL - это одно и то же. Если вы затем перейдете к реализации шаблона для вашего пользовательского интерфейса (например, MVVM), то модель все еще может быть BLL или отдельным битом кода, который вызывает BLL (а BLL не имеет прямого знания о модели). , В MVC модель обрабатывает данные, поэтому снова обращается к BLL (или даже может быть интегрирована и входит в BLL).

Мое предложение состоит в том, чтобы модель ссылалась на BLL, но не наоборот. Или вы можете интегрировать модель в BLL, в зависимости от сложности того, что вы строите.

Answer 2

Я не одобряю вашу текущую архитектуру.Конечно, разбиение вашего приложения на логические или физические уровни зависит от потребностей и сложности вашего проекта.но было бы лучше избавиться от текущей реализации и применить новую архитектуру как таковую:

• Модель домена : состоит из сущностей вашего домена, интерфейсов для ваших репозиториеви т. д.
• Репозиторий : реализует контракты репозитория, определенные в модели предметной области, возможны разные реализации репозиториев.
• AppService : состоитView Models, Messages, Application Services и т. д.это будет точка входа для пользователей во всю систему.
• Presentation : будет реализован шаблон представления, подобный шаблону MVP или MVC.

Это будет общая архитектура для многоуровневых приложений.попытаться программировать против интерфейсов, а не конкретных реализаций.Кроме того, чем больше вы абстрагируете свои бизнес-компоненты (уровни приложений) и чем больше вы используете преимущества использования Design Patterns и передового опыта, тем больше вы будете делать, чтобы ваша кодовая база была более масштабируемой, слабо связанной и лучше обслуживаемой.

Если вы разрабатываете продукт, а не просто пример приложения для себя, я бы посоветовал углубиться в Domain-Driven Design, Enterprise Application Architectures и Design Patterns, чтобы иметь возможность лучше моделировать потребности вашего бизнеса иреализовать лучшую и более надежную архитектуру.

Буду рада рассказать об этом подробнее, если вам потребуется дополнительная информация или конкретные вопросы [:

Answer 3

Вы можете создать интерфейсы для ваших классов bll, на которые ссылается ваш проект Model, и либо создать конкретный класс, используя шаблон фабрики, либо используя внедрение зависимостей. Просто будьте готовы добавить немного сложности вашим проектам. Альтернативой может быть взглянуть на ORM. Они заботятся о ленивой загрузке свойств, которые, похоже, вы пытаетесь достичь