I have the following situation:
A project MyCompany.MyProject.Domain
which contains my domain model, and partial classes (such as Contact
Your Utility
project referencing your MyCompany.MyProject.Domain
seems like a bit of a code smell. I'm assuming here that these are utilities that specifically work on domain objects--if that's the case, then why don't you include MyCompany.MyProject.Utilities
within your Domain
project (naturally, modifying the namespace accordingly)?
In any case, the normal way to break these kinds of dependencies is to abstract what is required by one project into a set of interfaces, and encapsulate those in a separate assembly. Before doing that though, make sure that what you're doing conceptually is the right thing.
In your particular situation though, consider introducing an interface, viz., INameHolder
:
public interface INameHolder
{
string FirstName { get; set; }
string LastName { get; set; }
}
Then Contact
implements INameHolder
. INameHolder
exists in another assembly, let's call it MyCompany.MyProject.Domain.Interfaces
.
Then your Utilities
project references Interfaces
(not Domain
) and so does Domain
, but Interfaces
doesn't reference anything--the circular reference is broken.