system.data.objects dev guy : DDD

Links: EF4 Podcast, N-Tier Anti-Patterns, and some thoughts about DDD

dsimmons@microsoft.com — Wed, 03 Jun 2009 10:56:50 GMT

Here are a few more resources I hope you will find useful:

Recently I had a conversation about EF4 with Carl and Richard of .Net Rocks, and it went up on their site today. Have a listen at http://www.dotnetrocks.com/default.aspx?showNum=451.

In addition, I have an article about design/architecture decisions related to n-tier applications in the latest issue of MSDN Magazine. This article is actually the first part of a two-part series. Originally it was a single longer article that wasn’t so depressing as this one came out (all about what *not* to do without really giving any help on what you should do). There are some important concepts, though, so hopefully you’ll find something useful even in this first part.

At the same time that I’ve been busy with these, some other folks have been trying out the beta of EF4 and some very interesting posts are starting to appear like this dive into producing a POCO repository with the EF by Keith Patton and a great discussion of LINQ Expression Trees and the Specification Pattern by the EF team’s own David DeWinter.

- Danny

Non-scalar Value Objects aka "Complex Types"

dsimmons@microsoft.com — Sun, 17 Jun 2007 01:06:00 GMT

Yesterday there was a post on the ADO.Net Orcas forum asking if it is possible to map two entities to a single row in a single table using the entity framework. The motivation/scenario behind this request was an entity which had an address as part of its properties plus the fact that there were other entity types which have very similar properties. The default mapping generated by the wizard just adds these as properties of the entity, but the preferred model would be that the entity has a property which is another class that groups the address properties together. That class would then be shared and used to model the address properties on other entity types as well.

The initial expectation of the person asking the question was that the address should be modeled as an entity type of its own, but they ran into two problems:

The address type doesn't have any appropriate property (or properties) to be its key.
Even if you did have appropriate properties for the key, the system doesn't let you map two entities to the same row in the same table.

The moment I saw this post, I was reminded of a discussion I had with Atul Adya early on in the entity framework project when we were trying to decide whether or not to support a modelling concept we call "complex types". Initially we had hoped not to introduce another modelling concept--aren't scalars, entities and relationships enough? Atul's viewpoint on the matter was: "If we don't support complex types, then someday, someone is going to ask us to map two entities to the same row in the database, and we won't ever be able to support that." Well, here we are. At the moment the EF CTPs do not support complex types, and as a result someone has asked for the other feature Atul was referring to (two entities mapped to the same row) which we just can't support.

Why can't we support two entities mapped to the same row? Well, first off the lack of a property or properties that can be the key is fundamental. Secondly, if you think about it, what would insert and delete operations that affect one but not both of the entities in a row really mean? Things get crazy really quick.

So the answer is to make sure the EDM supports the idea of complex types which Eric Evans calls value objects in his Domain Driven Design book. They have no identity on their own--their identity is slaved to the entity of which they are a part, but they do get their own class where you can add methods, validation, etc. and share it among all instances of that value type regardless of which entity they are a part of.

Fortunately, we did decide to implement complex types, and they will appear in an upcoming CTP.

- Danny

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

dsimmons@microsoft.com — Sat, 02 Jun 2007 07:54:00 GMT

Let me apologize up front for how long it has taken me to get back to this topic. What I can say, though, is that in the intervening interval I have devoted real time to studying agile design principles and domain driven design.

Initially I thought that some of the requests for *complete* persistence ignorance were the products just of dogma rather than fully informed and reasoned arguments, but when so many people give such passionate feedback it was clear that I needed to investigate more before I could claim to have any sort of an informed opinion. The product of my research is that I am now truly convinced of the importance of complete persistence ignorance for some scenarios. As a result, the team is now working on a series of product changes aimed at ensuring that a later move to complete persistence ignorance will not be a fundamental breaking change.

There's no question, though, that complete persistence ignorance comes at a price--both in the performance of applications built with "pure POCO", persistence ignorant domain models and as a result in the complexity of the entity framework which enables them. The additional complexity of the framework is not just about enabling such applications to function but a product of the fact that the performance degradation which results means that the framework must support a spectrum of flexible options between complete persistence ignorance on one hand and prescriptive architectures which build some persistence information into the domain model to improve performance on the other hand.

To make this more concrete, we have identified 4 elements of the existing entity framework design which block persistence ignorance. That is, 4 ways in which entities are currently required to have knowledge of the framework:

They must store a copy of an EntityKey.
They must provide change tracking notifications through a prescriptive interface.
They must be decorated with a series of attributes which provide additional metadata.
If they participate in relationships, the requirements are even more stringent as indicated by the requirement to implement the interface IEntityWithRelationships.

The first two requirements are enforced with the IEntity interface and must be addressed if we are to enable persistence ignorance at any point in the future. In fact a series of key object services APIs currently . At the same time each of these has significant performance implications. Choosing not to store EntityKeys on the entities, for instance, means that navigating from an entity to the ObjectStateEntry which matches it either requires a brute-force search of the ObjectStateManager or for the ObjectStateManager to maintain a dictionary mapping from CLR reference to ObjectStateEntry which is a significnat expense. Not supporting the change tracking mechanism means that the ObjectStateManager must cache a copy of the original values for each entity (all original values and they must be cache whether or not the entity is modified).

While I do believe that there are circumstances in which the loss of performance is a reasonable tradeoff for persistence ignorance, I also believe that for a great many applications, even where persistence ignorance is highly valued, there will come a time in the performance tuning process when one or another of these two compromises must be made. As a result, we are working on replacing IEntity with two separate interfaces and making both of them optional--which means the object services API signatures will change from taking parameters of type IEntity to type "object" and the framework must support multiple mechanisms for each of these.

The 3rd and 4th issues are, on the one hand, harder to correct, but on the other hand things which can be corrected later. At some point we will add an alternative mechanism for specifying metadata about the entity objects (thus freeing us from the hard requirement for attributes). Similarly, we can envision ways to enable POCO collection and reference mechanisms for relationships which can be added later as a complement to the existing prescriptive EntityCollection<T>, EntityReference<T> and RelationshipManager classes.

So, to sum it all up, message received: persistance ignorance is needed, and we're now working to deliver it. The first release of the entity framework likely will not have full support for it (there's just not enough time), but we will work to get into the first release the key changes which could not be made later so that the stage is set for the next release.

- Danny

Where’s the model? Is it the code or something else?

dsimmons@microsoft.com — Fri, 04 May 2007 09:24:00 GMT

A few weeks ago I had a very interesting email exchange with Jeffrey Palermo in which he raised some important questions about the Entity Framework. Here’s an excerpt from his original query (used by permission):

I've been thinking a lot about the model of the problem domain for a piece of software and the question of "what is the model". In domain driven design, the domain model in code is the canonical representation of the thoughts and concepts of the business domain (the model). Even so, the code is a very good _representation_ or _translation_ of the model as discussed by business analysts (it encorporates the concepts (entities) and behavior and rules of the business domain). The database schema is another translation of this model, but only geared toward storage of the concepts or entities. The behavior is absent here, just storage (for the most part).

This new EDM concept your team is introducing seems to be aimed at being the new canonical representation of the model. Here, there is an Xml file which describes the model or _represents_ the model, but is not the model itself. I remember when UML was really big, and folks were calling that the model. It could be described so well that it was called the model and all else was secondary. In the end, the UML wasn't executable, wasn't verifyable and wasn't testable, so it lost mindshare because when it came to working software that handled the business domain correctly, it still didn't deliver. There were tools that sought to generate software from the UML, but again, it didn't work.

I'm having a problem with your EDM xml file because I respect history. The Xml file that represents the model: how do we test it? How do I _know_ that it's correct? that is contains the right concepts (entities)? that every bit of it's behavior is correct? That every one of its rules is right?

I respect the coded domain model so much because it can't lie to me. I run my unit tests, and they pass or fail. I can demonstrate it. I can objectively prove its behavior and rules. The best representation of the model has to work 100%.

Maybe you've thought about this and have an answer. I've heard said that this new Xml artifact will be called "the model". Is that really the intended noun?

My response was that I hear and share concerns about the parallels to UML and the failed efforts of the past to make UML the center of the universe. (I personally think codegen from UML is so evil that I have taken to calling UML "the enemy" not because it's original purpose and ideas are bad—it can be a great tool for doing some sketches to communicate some ideas—but because it has been perverted to evil ends.)

We do talk about the EDM for an application as "the model", but that's just a verbal short-hand for "data model", which I believe is a critical distinction. We are explicitly NOT trying to define behavior in the EDM. The code is the right way to define that. We are, however, trying to define enough about the structure and constraints on the data that we can provide a rich set of services in a general fashion that still honor those constraints. If you think about it, this is very much like what the relational model does today vs. just doing your own file format. The relational model allows you to describe some things about the structure of your data so that the database and other parts of the system can provide services which help you manage that data. The idea of the EDM is to provide a higher-level of abstraction that gives more information about the structure of the data so that we can provide more services. This doesn't replace the object model or reduce its critical role; it just augments it with new services.

Once we start generating code from the EDM, things definitely become blurred a bit, but the explicit goal of the generated code is not to replace your object model—it's to save you some typing of repetitive things when you are building that object model. Further, the intent is that we would not require this generated code—you can always build your model completely on your own and just align the EDM with the shape of that model so that you can take advantage of the EDM-enabled services we provide (right now that means persistence/query, but eventually that means other things like reporting, replication, remoting, etc.).

A delay before I write more about persistence ignorance...

dsimmons@microsoft.com — Wed, 28 Mar 2007 06:02:00 GMT

I've promised to write more about persistence ignorance in the Entity Framework, and while waiting for builds during some late night coding binges for a deadline and various other distractions, I've been giving it a lot of thought. My conclusion, though, is that I'm not ready to treat this topic fairly. While I think I understand and have some useful things to say about how the Entity Framework does things (both in Orcas and in our vision for future releases), I don't think I understand the viewpoint of the folks asking for full persistence ignorance well enough yet. As you may have heard in the blogs of some other folks like Scott Bellware, Jeffrey Palermo and David Laribee, we had some great discussions during the MVP summit about these issues (thanks for the feedback all of you who were there!).

As you might take away from the blog postings about those discussions, it was a good exchange of ideas, and I think folks left with a sense that the long term vision is not so far off as they preivously thought, but everyone agrees that Orcas won't be a perfect fit for what some folks in the agile/domain-driven-design camp are looking for. While the amount of change that can happen between now and the release of Orcas is very limited, I want to work hard to understand this way of looking at the world deeply both so that we can get on track to converge in a later release and so that we can make certain nothing goes into Orcas that will prevent delivery of that vision later.

So, I'm taking my own little crash course on the subject which will by no means get me to the depth of understanding that some of you have after living and breathing this approach for multiple projects, but I'm hoping it will get me a bit farther along the curve before I respond on this subject and end up demonstrating my ignorance.