Circular Reference Between Data And Model Classes

Question

I have my C# project separated in several projects, so each will become a separate .dll after.

I have one project for my Model and one for my Data. Model is responsible for Business Logic and objects representations of what's in the Data Base. Data is responsible for creating the Data Base and general ORM operations. I also have a Desktop project that uses both Model and Data to interact with the user in a WPF Windows program.

Data has a reference to Model since it needs the objects in Model to create the DB for the ORM.

I wanted to add Business Logic into my models so they can be added to the DB, such as Person.Add() will add that person object instance to the DB, but When I add the Data project to the Model project as a reference Visual Studio says it can't be done since this will make a circular reference (which I agree).

How do you usually treat this cases? Is it there a way to keep this kind of projects decoupled or is it normal to merge Data and Model into one project?

Answer 1

The usual way is to have a third executable that takes Data and Model as references.

The way you tell you need two different DLL's is if you need to put each DLL on a different machine or in different software applications. Essentially, you need two DLL's if the distribution story for each DLL is different.

If you don't have that need, the cost of keeping them separate may outweigh the benefits, especially if they will be used together most of the time.

Also, may I suggest that Data and Model aren't necessarily the best possible division between two DLL's? There might be some better organizing principle, such as Accounting and HR, or ServiceLayer and ORM.

• mFeinstein: I have a third executable, I will edit my question to reflect this.
• Robert Harvey: I personally would put Data and Model in the same DLL, unless you have some compelling reason for keeping them separate.
• mFeinstein: I see your point...Well, I think this might get a web version so a different Data Base will be used, so Data and Desktop will need to be replaced. but the models will still be the same and do the same functionalities, that's the only scenario that I see where I can reuse this code. I agree on the naming, but it's a small project, I don't think I can break it in meaningful names and roles like that.
• Robert Harvey: Then provide interfaces for your Model, and swap out Data as needed.

Answer 2

This is common case where circular dependency can be broken by using an abstraction.

First, you don't want to have individual entities adding themselves into database. That breaks Single Responsibility Principle. For that you should make a separate class. But you still have a problem that this class depends on code inside Data module. This can be easily solved by introducing an abstraction. In Model, you define an interface, that represents operation like Save, Update, Delete, Load, etc.., and then implement that interface in Data module. Then, when application module creates the data, where the abstraction would is required, it passes in the concrete implementation from Data.

And because we like to name things, lets find a fitting name for the above construct. Lets see .. what about Repository? Well. Its not perfect, but it will do.

• mFeinstein: I read a lot about Repository and UOW before starting this project, and after a lot of research, I agree with many that say that Entity Framework is already a Repository and a UOW and building anything on top of this is just an abstraction of an abstraction.
• Walfrat: There is an Apache framework named ISIS that use RICH Objects that can consider that being able to save themselves is the responsability of the domain object. I don't use that but i think the concept is interesting