i was just going over the ProjectTracker examples from 4.0.1 vs my older 3.6.2 and i was wondering why all of the dataportal methods only use LoadProperty and ReadProperty for SmartDate fields and not on all properties when they are being set or retrieved?
wouldn't you want to bypass all the authorization checks and everything when performing the actual crud actions since all the property setters and getters already perform validation/authorization/business rule checking before it gets to the point of actually writing data to the database?
just wondering if there is any significant difference here that i am missing before i start writing anything
any help is appreciated, thanks
The property persistence code is in a "using (BypassPropertyChecks)" block, and so rules are suppressed for all the code. However, the SmartDate property is actually a string property, with a SmartDate backing field. So you can't set the property directly, because it is the wrong type. Therefore LoadProperty/ReadProperty are used to access the field value directly, bypassing the property entirely because it is the wrong type.
ah, yes i started looking at that block in the dataportal_create method and noticed it was in the other methods as well but wasn't sure about its full purpose along with smartdate properties, thanks for clarifying this!
as always, thanks for a great product, CSLA has made software development here for me and my team a much more streamlined and logical process
just out of curiosity why dont you use ByPassPropertyChecks in the child object dataportal methods? they are all just using LoadProperty it seems
ProjectTracker is very out of date. It was really last updated for the 2008 book.
The best overall sample right now is Samples\Net\cs\SimpleNTier
Copyright (c) Marimer LLC