http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Dan, Regarding change tracking and performance. My apprach has been to first have a light weight read-only Entity without any change tracking plumbing. In many cases Entities are read much more than they are written to so you get performance / footprint gains. When tracking state it can be done on the Entity or in a State Manager, I have done this both ways and yes it goes againts POCO but a read-write Entity by design needs change tracking so I choose to place it in the Entity, in the end it's a matter of choice, each will be more or less performant depending on the end usage scenario. Writes in most cases happen much less than reads so I think it's a non issue if read-only is used. I have no Idea what you are doing with EF collections, lazy and aggressive loading, and concurency. Entity Relations and Inheritance are the more complex issues. Why don't you start with some code and relationship scenarios and post for feedback, you could also enable anonymous comments on your blog. http://ayende.com/2489/persistence-ignorance-in-the-entity-framework#comment3http://ayende.com/2489/persistence-ignorance-in-the-entity-framework#comment3Mon, 04 Jun 2007 11:54:12 GMTCustom types means that I have data in the database that reside in one or more columns to which I want to do translation in my model. Simple examples, "yes"/'no" field to boolean, Amount/Currency columns to Money object, BINARY to System.Drawing.Image, etc. There are various scenarios around that, usually when integrating with legacy databases, but not just there. Extensibility of persistence approaches - the ability to extend the way that the framework get the data. This is a wide topic, but it include anything from being able to provide custom SQL, custom SQL generators, talking to non relational sources, etc. All within the framework. It should be something that I, as the end user of the framework, should have the ability to do - those are features that I have found crucial when it comes to integrating in most systems. http://ayende.com/2489/persistence-ignorance-in-the-entity-framework#comment2http://ayende.com/2489/persistence-ignorance-in-the-entity-framework#comment2Mon, 04 Jun 2007 03:26:07 GMTThanks for the response to my posting! Implementing PI in the EF isn't going to create problems with the existing infrastructure--it's just a matter (as always) of picking the correct features and then being careful to implement them. With regard to the two issues... The problem with not storing an EntityKey on the entity is not that we don't have the information somewhere else, you are right that we do, it's more a matter of the efficiency of navigating from an entity back to the place where the additional information is stored. The entity key is just a more efficient way of doing this navigation--all of the additional information is stored indexed by EntityKey. If you have the entitykey on the entity, then it's easy and efficient to get to the extra info, but if you don't have the entitykey on the entity, and the entity is all you have, then you need a different kind of lookup--either brute force or an additional index (in this case a dictionary). We will support both mechanisms, but the perf is affected. In many cases, the affect won't be large, so it's fine, but in large scalability situations it does become an issue. As you might expect, since the EF is a core framework we are giving a lot of attention to performance in an attempt to keep the overhead to an absolute minimum. So we're very sensitive to this kind of thing. With regard to the original values, in the EF today (and in the future if you opt-in for change tracking directly from the entity), we can store original values on a value-by-value basis only when the property in question is modified. If you don't provide notifications at just the right time, though, the framework must store the original values ahead of time which means storing more copies of the data than may strictly be necessary. Again, this is not a big deal for some scenarios but can be a big deal in others. Custom collections is something I also believe important, but unfortunately I doubt we'll be able to enable them for the first release--that will probably have to wait for the next release. With regard to extensibility mechanisms, I'd love to talk about what kinds of mechanisms you have in mind and think would be most helpful. Custom types is an interesting one--I assume that you mean custom primitive types with "conversion" of some sort between what's actually stored in the database and that type. I don't know how far we'll be able to get in that direction this time around, but it is something we're talking about to a certain extent. One interesting question is whether it's reasonable to model these with custom classes which have properties or fields that are 1-1 with the database (what we call complex types in the EF and will definitely be supported), or if we have critical scenarios where you want a custom type which requires custom code to convert from values in the DB to the custom type fields and back. Also, what do you have in mind when you talk about extensibility of "persistence approaches"? Again, thanks for the thoughtful response. - Danny http://ayende.com/2489/persistence-ignorance-in-the-entity-framework#comment1http://ayende.com/2489/persistence-ignorance-in-the-entity-framework#comment1Sun, 03 Jun 2007 21:10:36 GMT