0

I was reading a book learning API in .NET when I ran into the expression "persistence ignorant", I don't know what it means! The text is as follow:

What’s the Distinction?

Let’s step through each of those classes:

• Model: Represents the internal domain data of our application (the M in MVC).

• Data Transfer Objects (DTOs): Are the representations of our Domain Models to our external consumers, meaning that we don’t expose internal implementation detail (our Models) to external concerns. This has multiple benefits as we’ll discuss later.

• Data Access (aka DB Context): Takes our Models and represents (or “mediates”) them down to a specific persistence layer (e.g., PostgreSQL, SQL Server, etc.). Going forward, I’ll refer to our Data Access class as a “DB Context” which is a technology-specific term taken from “Entity Framework Core” – don’t worry; more on that later .

• Repository: Provides a technology agnostic (or persistence ignorant) view of our permanently stored data to our application.

So Would anyone explain it to me that what the expression persistence ignorant means?

General Grievance
  • 4,555
  • 31
  • 31
  • 45
Hossein
  • 142
  • 10
  • 4
    https://stackoverflow.com/questions/1974735/what-exactly-is-persistence-ignorance – Jonas Metzler Apr 26 '22 at 15:59
  • It means a view that is unaware of and does not care about the underlying persistence mechanism. – Rotem Apr 26 '22 at 15:59
  • 6
    It means the repository layer shouldn't _care_ about how the data might be persisted - it's an abstraction layer that's supposed to work the same regardless of whether you're using a database, a file, or something else. In other words, the repository type "is **ignorant** of the underlying storage **persistence** mechanism" – Mathias R. Jessen Apr 26 '22 at 15:59

1 Answers1

1

Making your software program 'persistence ignorant' is in-line with following the Inversion of Control principle. Essentially, you are building your program to not be 'hard coded' to the database of choice, but instead your code is 'programed to the interface'. (your application services would be using an interface in the ctor) When you follow the IoC principle, you create an interface for your repositories such that your caller (a service) has a DI injected instance of the class. This makes your code more adaptable to change since you can , for example, mock the repository during unit testing, test your application services in isolation (Separations of concerns), and change your persistence store later. This also follows the separation of concerns. Please let me know if this helps. I also have some books on this.

Judy007
  • 5,484
  • 4
  • 46
  • 68