Sal,
I work with Chris (ok he's my boss)
Another thing we do is use reflection to see the calling assembly, this
same approach could be used for dirty checking
set
{
DateTime dtStartDate = Entity.StartDate;
Entity.StartDate =
ReportChange(Assembly.GetCallingAssembly(), ref dtStartDate, value);
}
/// <summary>
/// The implementation of each ReportChange overload.
/// </summary>
[System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Design",
"CA1045:DoNotPassTypesByReference", MessageId = "1#")]
protected T ReportChange<T>(Assembly a_oCallingAssembly, ref T
a_oOldValue, T a_oNewValue)
{
// The calling assembly is used to detect whether property
setters are being called from
// data abstraction or external, i.e. XML serialization or
database persistence, software.
ScrubData<T>(ref a_oNewValue);
ScrubData<T>(ref a_oOldValue);
if (((a_oOldValue == null) && (a_oNewValue != null)) ||
((a_oOldValue != null) &&
(!a_oOldValue.Equals(a_oNewValue))))
{
if
(a_oCallingAssembly.GetName().Name.StartsWith(_sRootNamespace))
{
ObjectIsDirty = true;
}
//Validate<T>(ref a_oNewValue);
//assign value
a_oOldValue = a_oNewValue;
}
return a_oOldValue;
}
Where
-- Lazy load example
get
{
return
GetDataObject<ClaimFirmErrorAndOmission>(Assembly.GetCallingAssembly(),
ref _oClaimFirmErrorAndOmission);
}
/// <summary>
/// This method should be used by DAL-implementation only property
getters that load a single foreign key object.
/// It will perform the work of lazy loading data into a data
object. It will only lazy load
/// objects when the calling assembly is a DAL assembly. This is
because we don't want persistence services
/// to call back into themselves for lazy loading.
/// </summary>
/// <typeparam name="ImplType"></typeparam>
/// <param name="a_oCallingAssembly">Calling assembly.</param>
/// <param name="a_oChildDataObject">Child data object.</param>
protected ImplType GetDataObject<ImplType>(Assembly
a_oCallingAssembly, ref ImplType a_oChildDataObject) where ImplType :
DataObject, new()
{
if
(a_oCallingAssembly.GetName().Name.StartsWith(_sRootNamespace))
{
GetDataObject<ImplType>(ref a_oChildDataObject);
}
return a_oChildDataObject;
}
-----Original Message-----
From: Sal Bass [mailto:salbass...@hotmail.com]
Sent: Thursday, May 28, 2009 1:43 PM
To: user-cs@ibatis.apache.org
Subject: RE: Dirty Tracking Issue
Could you post a brief example?
----------------------------------------
> Subject: RE: Dirty Tracking Issue
> Date: Thu, 28 May 2009 12:34:09 -0600
> From: christopher.pot...@nfs.stoneriver.com
> To: user-cs@ibatis.apache.org
>
> Hi Sal:
>
> We've implemented a very similar piece of functionality in our
organization. We leveraged .Net's explicit interfaces feature to address
the complex property issue you describe below. The explicit interface
properties are used by non-iBATIS object model consumers and the actual
implementation properties are used by iBATIS. This allows the
functionality in the object model to distinguish behavior amongst
multiple model consumers. Another advantage we've found with this
approach is in the area of lazy loading. We can engage lazy loading when
we're a non-iBATIS object model consumer and avoid it when iBATIS is
populating the object model.
>
> I hope this helps,
> Chris Potter
>
> Confidentiality Notice: This E-mail message, including any
attachments, is for the sole use of intended recipient(s) and may
contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply email and
destroy all copies of the original message.
>
>
> -----Original Message-----
> From: Sal Bass [mailto:salbass...@hotmail.com]
> Sent: Thursday, May 28, 2009 11:55 AM
> To: user-cs@ibatis.apache.org
> Subject: Dirty Tracking Issue
>
>
> I am having a dilema with implementing dirty tracking on my entities.
I am using AOP to mark an entity as "dirty" when a property is set. The
problem occurs when I load the entities using Ibatis because it sets the
properties during mapping which makes the entity dirty (no, I can't use
constructor mapping here). So, I use a RowDelegate to mark the entity
clean before returning it. Works great....except for when I am loading a
root object with several complex properties (ILists of other entities).
The RowDelegate is obviously not fired for each complex property, so
they are returned as dirty.
>
> Any idea of how I can get at all of the complex properties to mark
them clean before returning the entity?
>
>
>
> _________________________________________________________________
> Hotmail(r) goes with you.
>
http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tuto
rial_Mobile1_052009
_________________________________________________________________
Hotmail(r) goes with you.
http://windowslive.com/Tutorial/Hotmail/Mobile?ocid=TXT_TAGLM_WL_HM_Tuto
rial_Mobile1_052009
