Структура проекта для N-уровневой архитектуры в .Net - уровни перекрестных ссылок

Question

Я реализую N-уровневую архитектуру в .Net, состоящую из уровня сущностей, уровня DAL, уровня бизнеса и уровня пользовательского интерфейса.

Объекты, в дополнение к примитивным полям,содержат свойства навигации.Примером этого может быть объект Invoice, который имеет свойство InvoiceLines, которое должно возвращать все объекты InvoiceLine, связанные с родительским объектом Invoice.

В связи с тем, что существует бизнес-логика, которую необходимо применить кэти InvoiceLines, как только они были извлечены из среды персистентности и не хотят дублировать код, свойство InvoiceLines в сущности Invoice заполняет себя посредством вызова метода GetInvoiceLinesByInvoiceID в бизнес-логике, которая возвращает IEnumerable.

Моя проблема в том, что я не могу разделить слои на отдельные проекты, поскольку проект Entities зависит от проекта Business, а проект Business зависит от проекта Entities, тем самым вводя перекрестную ссылку.В настоящее время у меня есть все 3 слоя (Entities, DAL и Business), живущих в одном проекте, который работает нормально, но означает, что я не могу использовать только Entities среди других решений.

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

Может кто-нибудь предложить более подходящий подход или каким-то образом я могу это сделать, хотядержать мои слои в отдельных проектах?

Cheers

Answer 1

Я сам был в этой ситуации несколько раз, и обычно есть простой выход.

Я сделаю несколько предположений здесь, но, надеюсь, они будут правы. Если вы используете подход, основанный на интерфейсе, ваша бизнес-логика будет реализовывать некоторый интерфейс, а ваши сущности будут реализовывать некоторый интерфейс. Любая зависимость от сущности от бизнес-объекта должна быть только от интерфейса и наоборот от бизнес-объекта до сущности. Это должно упростить разделение интерфейсов на отдельный проект (или, может быть, на два), а затем разделить вашу бизнес-логику и конкретные сущности на их собственные проекты, которые должны будут ссылаться только на сборки интерфейса.

Надеюсь, это имеет смысл.