Hi,
I have EditableRootObjectA which has EditableChildObjecB. I am adding an item to EditableChildObjecB and saving the EditableRootObjectA , before saving I am checking object.IsSelefValid it always returns True and executing the DataPotal_Update, I tried to debug this issue and found that if I call Me.ValidationRules.CheckRules() in EditableRootObjectA constructor , then it cheks the validation rules and displaying the brokenrules information and also the IsSelefValid return false.
I just want to see is there any otherway to check the validation rules apart from calling from constructor.
#Region "Contructor(s)"
Private Sub New()
Me.ValidationRules.CheckRules()
End Sub
#End Region
Calling this in the constructor isn't really safe, because the first instance of your type may not have any rules when this runs in some cases.
You should be using the data portal to create instances of your type, and then you should call CheckRules in the DataPortal_Create/Fetch methods.
In fact, in 3.8 and higher, the default implementation of DataPortal_Create does this for you, so by default when you create a new instance of a type through the data portal the rules are automatically run.
This is why I recommend (in .NET) that all business types have a non-public default constructor - to force the use of the data portal.
Ok, We are using version 3.8.2.0, As you mentioned the DataPortal_Create does this, but DataPortal_Fetch is not calling the CheckRules so I assume we have to call " Me.ValidationRules.CheckRules() " in the DataPoratl_Fetch otherwise while saving RootObject the IsSelfValid always returns true and not cheking the validationrules.
Please confirm.
Private Shadows Sub DataPortal_Fetch(ByVal criteria As SingleCriteria(Of User, System.Int32))
Map(reader) 'assume reader code is above
Me.ValidationRules.CheckRules()
End Sub
>> but DataPortal_Fetch is not calling the CheckRules <<
I believe that is correct. I think the assumption is data in the database is valid so don't need to run validation rules. As you mention you can run the CheckRules when needed.
Right, Fetch doesn't call CheckRules by default, because (I think) most people don't want to automatically run all their rules when loading data from the database - that's a very possible perf issue.
But if you need to run the rules, that's fine - just call CheckRules at the end of Fetch.
Ok, The reason for calling in the DataPorta_Fetch is when updating the rootobject DataPorta_update is not validationg the rules if I don't call checkrules in Fetch. Another question the DataPortal_Update should CheckRules by default , right? The DataPortal_Update is not checking rules if there is change in child and updating the root.
DataPortal_Update does not call CheckRules by default. Only Create does this.
If you are in an n-tier model running on a corporate LAN, most people wouldn't recheck the rules on the server, trusting that they were checked on the client and that Save() wouldn't have even allowed a call to the server if there were any broken rules.
The most typical scenario is one where we trust that if the client checked the rules we don't need to recheck them on the server. This is because to bypass the normal processing, a would-be hacker would need to either hack into the client side appdomain, or use a packet sniffer to capture, rewrite and replay the data portal service calls. So in no case are we defending against normal users or developers.
If you are actually worried that the client won't run the rules, then a cheap solution is to call CheckRules at the start of your Insert/Update/Delete methods on the server. But my recommendation is that if you don't trust the client, then you should switch to an SOA architecture - which is much more expensive, but is the correct solution when dealing with a scenario where you honestly think the client and/or network will be hacked.
Copyright (c) Marimer LLC