Where should we calculate fields?

Question

I'm currently working in a Silverlight / MS SQL project where the Entity Framework has not been implemented and I would like to know what's the best practice to deal with calculated fields in this particular situation.

Considering that some external system might also consume my data directly in the DB or thru a web service, here's the 3 options I can see right now.

1) Force any external system to consume data thru a web service and create all the calculated fields in the objects only.

2) Create the calculated fields in a DB view and resync your object with the server each time a value needs to be calculated.

3) Replicate the calculation rules in the object and the database view.

Any other suggestions would also be welcomed.

Answer 1

I would recommend to follow two principles: data decoupling and minimum functionality duplication. Both would suggest to put your calculations in one place only, and serve them already calculated. So I would implement the calculations in the DB, and serve them via a web service.

However, you have to consider your particular case. For example, if the calculations are VERY heavy, you could delegate them to the client to spare server resources. This could even be the reason you are using Silverlight. I am in a similar situation on a project, and I found that the best compromise is to push raw data to the client and have it do the heavy computations.

Answer 2

Having a best practice or approach for this kind of problem is difficult as circumstances change what was formerly a good approach might start to seem less useful. That said where possible I would do anything data related at the DB level including calculated fields. This way you know no matter where you are looking at the data from you will see the same results. So your web service, SQL reporting and anything else that needs to look at or receive data will see the same result.