Update on Computed Properties
A while back I wrote a post that introduced the concept of Computed Properties. Since that time we’ve had a number of conversations with both customers and internal partners and we’ve had some new ideas, that have changed our thinking somewhat.
- First off we decided to implement Model Defined Functions, which are significantly more powerful and flexible than Computed Properties, and provide overlapping capabilities.
- Computed Properties on the other hand, would never have been structurally part of the entity, which lead to some tough choices and probable customer confusion:
- Do you always pay the cost of materializing the Computed Property even when it is not required?
- What about if there are lots of Computed Properties on the Entity?
- Today in order to materialize an Entity and it's properties, computed or otherwise, the Entity Framework needs access to setters. Unfortunately the existence of the Setter, sends an erroneous message that Computed Properties can be altered and persisted.
- Upon further investigation we discovered that Computed Properties didn't actually address the requirements of Reporting Services, which was one of the original drivers for Computed Properties. Our original design called for computed properties to operate over an instance of an Entity, and it turned out that Reporting Services needed computed properties to operate over both an instance and a set of instances. Model Defined Functions on the other hand are flexible enough to handle both of these scenarios.
- In the future it may be possible to gain all the benefits of computed properties without any of the above issues, by extending our integration of Model Defined Functions with LINQ so that the [EdmFunction] attribute can be applied to CLR properties too.
If we did this the first parameter of the specified Model Defined Functions could be mapped to be the CLR type containing the property itself. This would allow a Computed Property, backed by a Model Defined Function, to be used in a targeted way in LINQ queries, without any of the illusions that this might somehow be set-able or structurally part of the entity.
Given all these points we started to think Computed Properties just weren’t as important.
We think our best course of actions in the short term is 1) to focus on supporting Model Defined Functions and 2) ask for your feedback on the relative importance of Computed Properties given the points listed above.
So what do you think?
Do Model Defined Functions address most of the scenarios for Computed Properties?
Particularly if in the future we can treat CLR properties as stubs for Model Defined Functions?
As always we are very keen to hear what you think.
Alex James
Program Manager
Microsoft
This post is part of the transparent design exercise in the Entity Framework Team. To understand how it works and how your feedback will be used please look at this post.
NB: For more background on the origins of [EdmFunction] check out this post.
