Tag Entity Framework
EF Core 2.1 vs NHibernate 5.1: DDD perspective
UPDATE 3/5/2020: I’ve expanded on this article and updated its content for EF Core 3.1 in my new Pluralsight course DDD and EF Core: Preserving Encapsulation.
That was probably a long wait for those of you who follow my blog. But, better late than never, so here it is: another comparison of Entity Framework and NHibernate, in which I bash EF Core and present it as an unbiased review. Just kidding, I do try to be unbiased here to the best of my skills.
Having the domain model separated from the persistence model
In this post, I’d like to write about a pretty common discussion in DDD circles: should one have the domain model separated from the persistence model? In other words, should you map your domain objects to the DB tables directly using an ORM or would it be better to use a separate set of Data Access Objects (DAOs) instead?
Do you need an ORM?
Do you need an ORM for your project given you use a relational database? And not just some lightweight like Dapper but a big one: NHibernate, Entity Framework, Hibernate? I’d like to address this question with this post.
Separation of Concerns in ORM
Last week we compared Entity Framework and NHibernate from a DDD perspective. Today, I’d like to dive deeper into what Separation of Concerns (SoC) is and why it is so important. We’ll look at some code examples and features that break the boundaries between the domain and persistence logic. Separation of concerns in ORM There are several concerns we deal with in software development. In most applications, there are at least three of them clearly defined: UI, business logic and database.
