Computed Properties One Pager

Alex James Is on Point for the Ef dESIGN bLOG

Tim Mallalieu's Blog. — Sat, 28 Jun 2008 17:18:12 GMT

Although we want all folks from the team to be able to post content as they saw fit on the EF Design

re: Computed Properties One Pager

PeterV — Sun, 29 Jun 2008 12:37:30 GMT

Those computed properties could be very handy in certain cases! Like when you are keeping 'length', 'height' and 'width' properties and want to have a property 'volume' that is calculated for you.

One thing I'm thinking about is how exceptions raised while evaluating the expressions would/could be handled.

What if in the example

it.Mother.Address

</DefiningExpression>

</Property>

Mother is null, will there be an exception thrown? Or what happens when you do some calculations and get a DivideByZeroException? Will it be possible to put a try/catch inside the DefiningExpression tag?

Or are exceptions always thrown and is the caller responsible for handling these exceptions?

Kind regards,

Peter

re: Computed Properties One Pager

JorgeLeo — Mon, 30 Jun 2008 16:15:29 GMT

To be honest I don't get this one.

If we are moving into POCO... Why would I define computed properties in the scheme map? What I would do is to have read only properties in C# (or whatever other language) with the formula. Done!

I'll check for my nulls, I have a much richer environment to express my formulas, and it keeps me in the POCO filosophy.

The only place where I can see some use of it is when the value of a property mus be calculated as an aggregation of some child objects. But there are already so many ways to do it.

Regards.

Jorge

re: Computed Properties One Pager

timmall — Mon, 30 Jun 2008 19:12:19 GMT

@JorgeLeo

POCO works if you have classes.

As Alex mentioned, the primary scenario for this is Reporting Services. In reporting services there are no classes, Reporting Services will work against the Entity Client (the EDM aware ADO.NET Provider) and will query using ESQL and get back readers. In this case the computed properties need to be defined in the model they cannot be defined in classes.

re: Computed Properties One Pager

JorgeLeo — Mon, 30 Jun 2008 20:52:20 GMT

@timall

I understand that the primary scenario is for reporting purposes.

Still I disagree.

If there is a calculated value that needs to be displayed as part of the form, then it makes sense to have a calculated property. The class should "know" about the results that the class calculates. The knowledge of the formula and its meaning in the business semantics is something that the class should know.

Since the class produces the result, this result can be persisted with the rest of the properties. In other words, if the storage is a database (but Persistence Ignorance can override this example), another column needs to be added in the database for the read only property, and it contains the result of that calculation for that particular object.

From a reporting perspective this is much more efficient since the results are already calculated. From a model perspective it reduces the places where the formula is represented to a single place, in the property definition, added bonus: easier maintenance, and as opposed to having the formula replicated in the report too.

If the formula needs only to be displayed as consequence of a report, still the class (in my very personal opinion) should be the right place to put it. Like in the case of (for the sake of the argument) windows forms, where we use an MVC model, it should be the same case of the reports. Meaning, do not storing business knowledge in the report definition, the report should be just a read-only paper (or screen) representation of the data. The fact that it makes sense for a particular field to be totaled (as opposed to average or something else) is part of the business knowledge, not part of the report presentation.

In other words, I think is a reasonable expectative that the reporting tool should be able to query from the POCO, not from the storage. Persistence Ignorance also can say that the objects are stored in a place where common reporting tools cannot reach.

Reporting services should be extended to support Persistence Ignorance.

My 2 cents...

Jorge

re: Computed Properties One Pager

timmall — Mon, 30 Jun 2008 22:30:23 GMT

@Jorge

I think you are missing the point.

We are doing work for the RS team, the RS team will not use classes, they will just use EntityDataReader there are no classes in their scenarios.

The EDM is a data model that is intended to be used across a number of SQL Server services, such as RS, where there is no expectation that CLR classes exist. This scneario is not about POCO or Prescribed Classes, this is about Entity Client and the EDM.

re: Computed Properties One Pager

JorgeLeo — Mon, 30 Jun 2008 23:04:02 GMT

@timmall,

Question... what comes first? RS or EF?

Looks one of them will do a sacrifice, and based on your response it sounds like it was already decided EF.

If RS comes first, then the point is null. Duplication of formulas will be a necesary evil.

re: Computed Properties One Pager

jrista — Sat, 26 Jul 2008 08:48:52 GMT

@JorgeLeo,

You should open your mind up a bit and look at the larger picture the EF team is targeting. As Timmal said, this 1-Pager has to do with EDM. EDM is a conceptual design language, and the ultimate goal is to provide a common conceptual definition framework that can service many higher level needs, not JUST the needs of programmers. POCO is a need for programmers, and as you said, computed properties can just be done in the class.

However, when it comes to a different higher level need, such as reporting, there IS no class. RS consumes entities directly from the conceptual model. Not only that, but the developer of a report does not neccesarily have the need, desire, or even right to modify the database to add a computed column or modify a view to provide the required computations at the lowest possible level.

Having the capability to define computed properties in an expressive manner directly as part of an entity will be a huge, timesaving boon.

re: Computed Properties One Pager

jdevonshire — Fri, 01 Aug 2008 00:15:48 GMT

Wouldn't the value of a computed property be easier to derive if System.ValueType supported an OnChange event? The event would facilitate rippling and tracking changes across a computed value graph allowing Calculated Properties to reference Calculated Properties in other Entities within the conceptual model.

Implementing the event in the base Framework shouldn't be too intrusive to merit consideration.

re: Computed Properties One Pager

shawn — Thu, 30 Oct 2008 05:39:16 GMT

I think something like this could be very useful!

re: Computed Properties One Pager

Alexnaldo Santos — Fri, 26 Dec 2008 21:47:51 GMT

Can I uses Compoted Properties into eSQL ? Like :

"select VALUE from Person as p where p.Mother.Id=10"

where Mother is a composed property...

re: Computed Properties One Pager

AlexJ — Thu, 01 Jan 2009 01:23:39 GMT

Alexnaldo,

Hi, Alex James here... long time no talk.

I will be writing a follow-up post on computed properties and something called Model Defined Functions soon. That will hopefully answer all your questions!

Cheers

Alex

Update on Computed Properties

Entity Framework Design — Tue, 13 Jan 2009 07:27:39 GMT

A while back I wrote a post that introduced the concept of Computed Properties . Since that time we’ve

Entity Framework - что нас ждёт в будущем

Заметки о Net технологиях — Tue, 20 Jan 2009 12:32:17 GMT

Привет всем! At Microsoft PDC2008, Program Manager Tim Mallalieu presented "Entity Fretwork Futures"...

re: Computed Properties One Pager

Brian P — Fri, 13 Feb 2009 19:32:11 GMT

This is great news. I agree with JorgeLeo in the sense that it would be nice if the CLR classes were the model and RS could use these classes as their source. I would rather put these calculated properties in code. But, you can't use those properties in your linq queries, so this will solve that right? So I'm glad it will at least be possible. Any chance that you guys could work on this scenario?

re: Computed Properties One Pager

Tanveer Badar — Tue, 03 Mar 2009 13:53:27 GMT

@ jdevonshire

Change notification for value types looks like a very desirable feature, until you look at the consequences.

Value types have no hidden costs when it comes to storage. This is the reason you cannot do things like lock( i ) where i may be an integer.

Consider how such a change notification would be implemented for a simple case of integer.

int i = 5; // This may translate to push 5 in x86 terms.

i = 6; // This may translate to mov eax, 6

If the runtime was supposed to raise a change notification at the second line, a simple mov won't do that. You need much more baggage than that. A place to hold the delegate reference, a slot in function table to invoke that delegate, etc. Its not a trivial thing to do.

re: Computed Properties One Pager

JLSPublic — Thu, 16 Apr 2009 18:38:34 GMT

@Tanveer Badar

What about having the Property "Set" methods on classes automatically raise the change notification? It seems like a straightforward thing for the CLR to do.