Persistence Ignorance: OK, I think I get it now.

re: Persistence Ignorance: OK, I think I get it now.

Udi Dahan — Sat, 02 Jun 2007 13:07:02 GMT

First of all, that's great to hear.

Second, the context for persistence ignorance is the Domain Model pattern - I've got a write up about it here:

http://udidahan.weblogs.us/2007/04/21/domain-model-pattern/

That object model should be independent of UI concerns as well. The same goes for how the data in it get sent across the wire.

By keeping it isolated, we make it that much more testable. Since our complex business logic is embodied in it, we're really going to need to know if some change we made broke other assumptions.

That said, these concerns will definitely affect the way we design the domain model.

re: Persistence Ignorance: OK, I think I get it now.

rogerj — Sun, 03 Jun 2007 00:55:42 GMT

Danny,

Pingback from http://oakleafblog.blogspot.com/2007/06/entity-framework-updates.html

and thanks for the heads-up.

--rj

re: Persistence Ignorance: OK, I think I get it now.

dsimmons@microsoft.com — Sun, 03 Jun 2007 06:40:18 GMT

Yes, Udi, I have been spending a lot of time thinking about domain models, domain driven design and the like. And yes, certainly it makes sense to isolate the domain model from other concerns. We have been working for some time to isolate domain models from UI and to make reasonable patterns for remoting them without having an impact on the model. The question about persistence gets a bit interesting, though, given that often business logic needs to interact with some sort of persistence abstraction in order to retrieve or manipulate related domain objects. I've known all along that there's huge value in isolating the domain model from changes to the database (that's one of the great advantages of a system like the EF where you can refactor your database, change the mapping and keep your domain objects unmodified). What I didn't understand until recently was just how *completely* isolated it was important to make the domain model in some situations. In fact if you look at a variety of the popular literature on this topic, not everyone believes in total isolation (attributes can be a reasonable tradeoff, for instance, because they are relatively unintrusive, etc.).

In any case, we're now working to create a framework which enables a range of options so that you can be completely ignorant or you can bake various amounts of presistence awareness into your domain objects depending upon the needs of your particular situation.

I would also assert that nothing about the EF should prevent you from employing any of the techniques which you would normally use to achieve separation from UI or remoting/messaging.

- Danny

Persistence Ignorance in the Entity Framework

Ayende @ Rahien — Sun, 03 Jun 2007 22:56:22 GMT

Persistence Ignorance in the Entity Framework

re: Persistence Ignorance: OK, I think I get it now.

Udi Dahan — Tue, 05 Jun 2007 19:49:48 GMT

"The question about persistence gets a bit interesting, though, given that often business logic needs to interact with some sort of persistence abstraction in order to retrieve or manipulate related domain objects."

The logic within the Domain Model just navigates the object graph for retrieval, and calls methods (which change the object's internal data) in order to manipulate those domain objects.

In the case of improving the performance of object retrieval, you'll want a way to ask for an entire sub-graph to be loaded in a single database hit, rather than having objects loaded on demand as you navigate the graph. I've got a post up showing a design that clearly separates out the concern of defining object-graph retrieval here:

http://udidahan.weblogs.us/2007/04/23/fetching-strategy-design/

I've got another post up on showing different styles of having the domain model communicate out persistence demands to the Service Layer, which actually calls the "persistence abstraction". Take a look and tell me what you think:

http://udidahan.weblogs.us/2007/06/04/performant-and-explicit-domain-models/

re: Persistence Ignorance: OK, I think I get it now.

BenScheirman — Wed, 06 Jun 2007 20:31:34 GMT

I'm really pleased to hear this. I never did chime in publicly on the debate, but I'm firm with the PI folks.

But, as you say, there are cases when Persistence Aware objects give you a lot of benefits. We just want to be given the flexibility to choose.

Also, the most effective way that I have found to flesh out a good domain model is to actually write it test-first (for me, anyway). If that meant that I had to create a table (or tables) and setup connection information, then I'm going against the grain. The PI approach will allow me to worry about persistence once the domain model has settled some, so there isn't any wasted effort in mapping to the database so early on.

EF Persistence Ignorance Recap

system.data.objects dev guy — Wed, 26 Sep 2007 21:05:19 GMT

I had someone email me a question today about POCO, IPOCO, persistence ignorance and the EF, and I responded

ADO.NET Entity Framework Vote of No Confidence

BlogCoward — Wed, 25 Jun 2008 05:17:26 GMT

ADO.NET Entity Framework Vote of No Confidence