Update on Computed Properties

re: Update on Computed Properties

Kristofer — Tue, 13 Jan 2009 08:33:36 GMT

My 0.7 baht (== ~2 cent):

"<i>Do you always pay the cost of materializing the Computed Property even when it is not required?</i>"

No. Only materialize when called for, otherwise it is not a property or function; always materialized==fields. Always materializing would make computed properties and MDFs banned in many dev shops. (something that _always_ result in [hidden] overhead is a really good way to shoot oneself in the foot)

Even for non-computed members I think you need to re-think how entities are populated today [in EFv1]. Partially populated entities (without needing a new 'partial' entity definition in the CSDL) is something desperately needed. (northwind example: employee details without photo)

"<i>CLR properties as stubs for Model Defined Functions</i>"

No. At least not without a way to flag it as 'not part of the model', e.g. a "[NotInModel()]" or "[EFIgnore()]" attribute.

I think MDFs should be exposed as regular functions, not property gets. CLR properties on entities should be allowed _without_ anything under it in the model.

---

MDFs would already cover 99.5% of the usage scenarios I can imagine for computed properties. 100% if "reverse computation"/"property set" is not supported. That said, computed properties with reverse breakdown/"property set" definitions would be neat. E.g. person name parts <-> person full name.

re: Update on Computed Properties

efdesign — Tue, 13 Jan 2009 09:16:50 GMT

Kristofer,

Partial loading as you call it is definitely something we have been considering (i.e. the don't load the big blob unless I really need it scenario). It isn't looking likely in .NET 4.0 though.

CLR Properties without anything under them in the model are already supported. The caveat of course is the value isn't persisted and it can't be used in a LINQ Query. So I think this is a somewhat orthogonal idea.

Note: not adding the [EdmFunction] attribute to the CLR property would be the equivalent of adding your [NotInModel()] attribute.

So I see little point in the [NotInModel()] attribute, essentially it is the default state of a Property that has no corresponding Property in the EntityType.

Cheers

Alex

re: Update on Computed Properties

Kristofer — Tue, 13 Jan 2009 12:38:47 GMT

'Partial loading' should be really high up on the feature list IMO - it is very important from a performance perspective...

Ok, my bad re the attributes. I assumed that "CLR properties as stubs for Model Defined Functions" meant that CLR properties with no mapping would [by default] attempt to find/call a matching function.

Either way, separating properties and functions in the model so they map to properties and functions in the generated classes is probably a good idea. Very little overhead implementation-wise but allows users the flexibility to choose which one to use.

And as I mentioned - for properties, an optional definition for 'setter' logic (again defined in ESQL, RegExp, or a method call to an assembly or webservice) would open up a bunch of possibilities:

<DefiningExpression Type="Get" Language="ESQL">FirstName + ' ' + LastName</DefiningExpression>

</Property>

...or the appropriate extensibility interfaces allowing third-party implementations of the same. :)

T4 for code generation goes a long way towards the latter, but some additional extensibility points in the visual designer to complement that would be neat; allowing third-party extensions/add-ins to add new properties [mapped to their own 'structural annotation' members] in the designer etc

re: Update on Computed Properties

shawn — Tue, 20 Jan 2009 01:11:56 GMT

I think having some way to define Computed Properties, either directly or backed by Model Defined Functions, is critical for being able to fully express entities in an entity/object-oriented way. It allows you to define and query data as part of the entity/model itself. Often times this is the preferable way for computed data to be consumed. It certainly is in our scenarios. This is one of the features we are most excited about.

re: Update on Computed Properties

Pedro — Tue, 20 Jan 2009 16:16:25 GMT

Sorry to go a little of topic here, but I was wondering if I could download a preview version of EF v2 just to play with it.

Thanks.

re: Update on Computed Properties

dsimmons@microsoft.com — Wed, 21 Jan 2009 00:10:38 GMT

EF v2 preview is not available yet. We're working on that and will make something available as soon as we reasonably can.

- Danny

re: Update on Computed Properties

Pedro Brown — Wed, 21 Jan 2009 16:06:34 GMT

Thank you for your answer Danny.

I have to say that I'm really excited about what is beeing done in the EF. What I want to know is: Can we make suggestions to make EF more a MDD framework, or it's purpose is just to be an O/R M and leave the MDD area to Oslo?

Thanks.

re: Update on Computed Properties

Pedro Brown — Wed, 21 Jan 2009 16:17:56 GMT

Sorry, MDD is (Model Driven Desing), but I think that what you guys use is DDD (Domain Driven Desing).

Thanks again.

re: Update on Computed Properties

Ike — Tue, 17 Feb 2009 22:55:21 GMT

One great benefit of computed properties would be to add non-model data to entites being delivered via REST (ADO.NET Data Services). Interjecting "computed" data into my entites has become absolutely necessary and since I...

- can't do that with EF (computed properties would be nice?) so ADO.NET Data Services is out

- can't return a JSON-serialized object that includes a EF entity item from a WCF operation if that EF entity includes a reference to another EF entity (known issue...very specific error occurs if you try to do that)

...I have had to resort to creating separate contract types for each EF entity type I want to return as JSON.

If EF allowed me to add computed properties, I could scrap most of my contract types.