trjhtr

I was reading about anemic data models and rich domain models in DDD. I don't want to follow DDD completely but take rather pragmatic approach and just take some concepts out of it because clean ddd seems like an overkill. What I'm building is Web API (using ASP.NET Core and Entity Framework Core).

I don't want to maintain separate DTOs just for serializing and deserializing my models.

And I want to make most of the things like service layer and my controllers generic. Because it's mostly CRUD and logic is repeating - a lot of boilerplate.

I'm not planning to use any other ORM other than EF Core.

EF Core allows mapping to backing fields:

https://ardalis.com/encapsulated-collections-in-entity-framework-core
https://technet.microsoft.com/en-us/mt842503.aspx

Is it fine if I will design my models like this and at the same time use them as my DTOs for serialization and deserialization?

public class Player

 [JsonIgnore]
 public int Id get; set; 

 [NotMapped, Required]
 public PlayerInfo ActiveInfo get; set; // setter must be public to allow deserialization (or use custom resolver for json net)

 [JsonIgnore]
 public ICollection<PlayerInfo> PlayerInfos get; set; = new HashSet<PlayerInfo>();

 private Player()
 
 

 public Player(PlayerInfo info)
 
 info.IsActive = true;
 PlayerInfos.Add(info);
 

 public void SetActiveInfo(PlayerInfo playerInfo)
 
 var currentlyActiveInfo = PlayerInfos.SingleOrDefault(info => info.IsActive);
 if (currentlyActiveInfo != null)
 
 currentlyActiveInfo.IsActive = false;
 
 playerInfo.IsActive = true;
 PlayerInfos.Add(playerInfo);

 ActiveInfo = playerInfo;
 

This is controller:

public class PlayerController

 private readonly DbContext _dbContext get; set; 
 private readonly DbSet<Player> _players get; set; 

 public PlayerController(DbContext dbContext)
 
 _dbContext = dbContext;
 _players = dbContext.Set<Player>();
 

 // Create new player
 [HttpPost]
 public ActionResult<Player> Post([FromBody] Player player)
 
 if (!ModelState.IsValid)
 
 //Handle validation error
 
 // No service layer for the sake of simplicity.
 player.SetActiveInfo(player.ActiveInfo); // will use _activeInfo
 _players.Add(player); // begins tracking entity 
 if (_dbContext.Save() == 0)
 
 // handle error

 
 return player;
 

I was reading about anemic data models and rich domain models in DDD. I don't want to follow DDD completely but take rather pragmatic approach and just take some concepts out of it because clean ddd seems like an overkill.

I don't want to maintain separate DTOs just for serializing and deserializing my models.

I'm similarly pragmatic as you, and I agree with you in this situation.

KISS (keep it simple & stupid) applies here. If your application is not sufficiently large, a DTO layer abstraction is not necessary.

I have several colleagues who would disagree with this, this is an open discussion topic. Personally, I disagree with blindly implementing things just because it was needed in other projects. Before I implement something, I need to justify its existence in the current project.

I'm not planning to use any other ORM other than EF Core.

It's not so much about what you plan to use, but rather the chance of this changing in the future, and how prepared you want to be when it turns out you have to change it.

Is it fine if I will design my models like this and at the same time use them as my DTOs for serialization and deserialization?

Yes, as long as you're okay with the tighter coupling and don't start violating SRP by loading everything into your entity classes.

However, that is a separate discussion from whether or not you should use DTOs. You could just as well violate SRP on your DTO class.

As I explain here, the EF model is primarily a data layer. Its classes may be suited for other roles, but their primary responsibility should always be: smooth data access.

Your question is about combining three possible roles an EF model class could play:

1. A property bag that communicates data back and forth between the database and object-oriented code. That's obviously it's primary role.


2. A DDD class that encapsulates business logic, i.e. data and methods working on them (the OO principle).


3. A DTO class that communicates between some client (UI or B2B) and the business logic.

It may be perfectly valid to combine role 1 with one or both of the other roles, as long as role 1 isn't compromised in any way. Sometimes that's a thin line, but generally the Single Responsibility Principe is a good touchstone.

I can be short about combining role 1 and 3. This may be valid in simple CRUD functions, although I don't like the dependency on Json.Net in a data layer class. And who says that in each use case the same properties should be ignored? It's generally preferred to use dedicated DTOs for client traffic.

The DDD role is tougher to judge. Let me focus on your example.

The method...

public void SetActiveInfo(PlayerInfo playerInfo)

 var currentlyActiveInfo = PlayerInfos.SingleOrDefault(info => fo.IsActive);
 if (currentlyActiveInfo != null)
 
 currentlyActiveInfo.IsActive = false;
 
 playerInfo.IsActive = true;
 PlayerInfos.Add(playerInfo);
 ActiveInfo = playerInfo;

...relies on PlayerInfos to have been loaded. If they aren't you have to rely on lazy loading. Lazy loading is supported in EF-core since version 2.1 (currently in pre-release). For lazy loading the context must be active (not disposed) when the collection is accessed.

So there's a couple of things that may go wrong here:

1. 
   PlayerInfos isn't loaded and lazy loading isn't enabled: the currently active record isn't deactivated and you end up having two active records without even noticing it.


2. 
   PlayerInfos isn't loaded, lazy loading is enabled, but the context is disposed. Now an InvalidOperationException is thrown, like:
   
   

   
   

   An attempt was made to lazy-load navigation property 'PlayerInfos' on entity type 'PlayerProxy_3' after the associated DbContext was disposed.

   
   

   
   

To prevent these errors you'd want to ensure that whenever SetActiveInfo is to be executed PlayerInfos is eagerly loaded (using Include). Two options:

1. Since it may not always be clear if the program control flow will end up calling the method it may seem sensible to load the collection always. But that would require Include any old time Players are loaded, even when they're not needed.


2. Load PlayerInfos right before SetActiveInfo is going to be called (if possible).

Where's the DDD going here? For the first option the code always needs to know that Player must have loaded PlayerInfos and there may not be a single source of players: they may get loaded from the DbSet but also in Includes and navigation properties.

The second option is even worse: the caller is made responsible for Player's proper state.

In DDD you'd use a class that is guaranteed to have all data it requires to execute its methods properly. Objects of this class will be created solely by a factory that ensures their integrity. It's always safe to call their methods (Tell, don't ask).

So, to summarize, it may be possible to equip EF classes for executing business logic. It mainly depends on the extend to which it can be guaranteed that the data layer produces entities in the proper state.