Good Morning All,
I wanted to engage your thoughts on the Pros and Cons of utilizing Managed Backed Fields for ReadOnlyBase objects?
Are there any reason why we shouldn't use them (i.e. Performance)? Conversely are there any benefits to utilizing them?
The same pros and cons apply as with BusinessBase.
If you use managed backing fields:
If you use private backing fields:
That perf hit/gain is very dependent on what you do with the property values. There are really two things to consider.
First, in your data fetch processing, you can see a perf difference. This is typically only meaningful when loading a collection with hundreds or thousands of ReadOnlyBase child objects. Loading single objects, or collections with dozens of objects is fast enough that there's no realistic difference.
Second, in your business logic, if you are using the objects do to intensive computation algorithms, so you are accessing properties tens of thousands of times as you loop over the object graph as part of the algorithm (and I'm talking about non-typical stuff here), you can see a perf difference.
I recommend always using managed backing fields, and only falling back to private backing fields in specific objects where a perf issue is actually encountered. Premature optimization is an anti-pattern.
Thanks for the explanation.
The once scenario I’m am debating on whether to use managed vs. private backing fields is in regards to audit history in which we will be retrieving a collection of ROB child objects.
Unfortunately it is extremely hard to estimate the number of objects that will be retrieved as it will depend on factors as (user experience, age of the information, corrections made, etc…)
In this case would you still recommend utilizing the managed backed fields?
I believe the last two sentences of Rocky's post are instructive:
"I recommend always using managed backing fields, and only falling back to private backing fields in specific objects where a perf issue is actually encountered. Premature optimization is an anti-pattern."
That would say to me to use managed backing fields until your usage scenario dictates that you do something else.
Beyond that, while you may not be able to accurately predict the number of objects retrieved for any given retrieval, you should have some data available that you can use for analysis. A simple average across the spectrum of current historical data gives you a starting point, and from there you can do some analysis on the likelihood of data changes and the volume of audit records that will produce. You can come up with some pretty decent estimates without a lot of work.
You might also consider the "practicality" of the use case - if a given record has thousands of audit records associated to it, how useful is it going to be to your users to dump all that data to them? Most people don't just go browsing through audit history - they have a specific task in mind, and a specific set of data they are looking for that is constrained by date, user, etc. This should reduce your return data to a much more manageable volume. If you build your UI correctly, you'll keep your inexperienced users from pulling the whole data set. And in a compliance type of situation, where the scope of the data filter may be monthly (or larger), chances are the aren't going to look at it online - they'll want it in a report.
Just my $0.02...
- Scott
Scott,
Thanks for the additional input. Unfortunately we currently don't have a basis for the number of objects we may retrieve. Currently, only certain items are audited. We are in the process of a complete application rewrite and will be auditing everything (based on our Auditor's business requirements). Hence the reason why I had asked Rocky (in his professional opinion) whether managed vs. private backing fields should be used in an audit/log scenario.
I like your idea regarding providing a reduced result set based on the requesting user's selection (even though it was not requested in the business requirements document). I'll be engaging the various groups and pitch them the idea. Hopefully they’ll like it as well and ask for some revisions around the details provided.
In our scenario, an auditor/VP would review the entire history from inception to the current day in order to ascertain the validity of the information so it is conceivable that we would be providing a lot of data.
My advice stands. I'd implement with managed backing fields and keep my code simple. If I ran into a perf issue I'd go through the effort of making that ROB class use private backing fields. It isn't a hard conversion, especially for an ROB class where there are no business rules.
Copyright (c) Marimer LLC