Home/ Questions/Q 6192859
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-24T03:01:10+00:00

I’m implementing an N-Tier architecture in .Net, comprised of an Entity layer, a DAL

  • 0

I’m implementing an N-Tier architecture in .Net, comprised of an Entity layer, a DAL layer, a Business layer, and a UI layer.

The entities, in addition to primitive fields, contain navigation properties. An example of this would be an Invoice entity, which has an InvoiceLines property, which should return all InvoiceLine entities associated with the parent Invoice entity.

Owing to the fact that there is business logic which needs to be applied to these InvoiceLines once they have been retrieved from the persistence medium, and not wanting to duplicate code, the InvoiceLines property on the Invoice entity populates itself via a call to a GetInvoiceLinesByInvoiceID method within the business logic, which returns IEnumerable<Entities.InvoiceLine>.

My problem is this – I cannot separate out the layers into separate projects, since the Entities project depends on the Business project, and the Business project depends on the Entities project, thereby introducing a cross reference. I currently have all 3 layers (Entities, DAL and Business) living in the same project, which works fine, but means I cannot share just the Entities amongst other solutions.

I appreciate that by cross-referencing layers in this way I’m violating some principle, but it’s extremely convenient to have navigation properties populated on my Entities with business logic applied to them.

Can anyone please suggest a better approach, or some way I can do this whilst keeping my layers in separate projects?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ve been in this situation myself a number of times and there is usually a simple way out.

    I’ll make a few assumptions here but hopefully they’ll be right. If you’re using an interface based approach your business logic will implement some interface and your entities will implement some interface. Any dependancy from the entity to the business object should only be of the interface and vice versa from the business object to the entity. This should make it quite easy to strip the interfaces in to a separate project (or maybe two), then split out your business logic and concrete entities to their own projects which will only need to reference the interface assemblies.

    Hopefully that makes sense.

    • 0