Hi Anderson, thanks for your question.

Using fluent API to configure EF’s model would indeed help to avoid “polluting” model classes with EF-related details like the Table and Key attributes. However, Isolating our data access models from your domain entities is still desirable if we expect our application to grow in complexity.

On one hand, we want to design our domain entities only around business concepts and behaviors. On the other hand, data models will be designed with efficient storage and database practices in mind.

So, as we try to design our domain entities to closely model the business flows and nothing more, they will probably start looking less and less like our database structure.

In the article’s code, there’s already a small example of this: We can see how OrderItemModel (data model) includes both an OrderId property and an Order property pointing to its parent order. This is needed so entity framework can properly handle the relationship between the two tables in the database.

At the same time, the OrderItem class (domain entity) doesn’t need to include these properties since, at the domain level, we always deal with the entire aggregate. In our domain, the Items property on the Order class is all we need.

Of course, this is a very simple example and we could just live with a couple of extra properties and get rid entirely of data models and mappings ending up with a simpler solution as you said, that would be a perfectly valid design choice.

But, in an application with several aggregates and potentially tens or hundreds of database tables. Using the same set of classes to deal with both business and database concerns can quickly become cumbersome and end up coupling your business code to storage design specifics.

Hope this helps.

Hi Leong, thank you very much for your kind comment 🙂

We can very well base our repository implementations on MongoDB or any other NoSQL data store. In that case, we would typically replace entity framework’s DbContext and use MongoClient instead.

Try searching for “mongodb generic repository in c#” for specific examples.