Plugging into validator classes of other ORM frameworks within Dynamic Data

Question

User320031091 posted

 I'd like to plug into the support LLBLGEN has provided for dynamic data to leverage my existing validator classes and expose their validation to the dynamic data framework when build CRUD pages.  How can I best do this? I.e. I don't want to duplicate validation logic which exists in the LLBLGEN validator classes and also in new meta data classes - one mapped for each LLBLGEN entity

 

Answer 1

User1641955678 posted

I'm not familiar enough with how LLBLGen does validation.  Are you referring to attribute based validation (e.g. like [RegEx] in DynamicData), or to custom validation (more like throwing from OnXXXChanging in Linq To Sql)?

David

Answer 2

User320031091 posted

Actually I created this thread on the LLBLGEN forum

 http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=14330&StartAtMessage=0&#79914

 You can see I'm trying to do something similar to what Scott did on the business logic exception dynamic data tutorial i.e. throw a ValidationException from an On.. method called by LLBLGEN, but not the one called from LINQ to SQL. 

 

Answer 3

User1641955678 posted

It may be related to the specific time during which those validation methods are called.  Could you set a BP and get the stack when your Validate method gets called?

David

Answer 4

User1641955678 posted

Actually, it looks like it may be an issue with the LLBLGen data source, which is not firing its IDynamicDataSource.Exception event when an error occurs.

David

Answer 5

User-1938370448 posted

Actually, it looks like it may be an issue with the LLBLGen data source, which is not firing its IDynamicDataSource.Exception event when an error occurs.

 

Hi David,

I don't raise events when an exception occurs, and frankly I find that a weird way of dealing with exceptions: exceptions shouldn't lead to events being raised, exceptions have their own mechanism: they bubble upwards and end up in the catch clause designed to catch them. 

I see a big problem with this: every routine now has to have a try/catch wrapper to catch the exception and route it to the event handler, and it's also unclear to me what to do with the exception... swallow? I truly hope not. The main gripe with this system is that it's not really failproof: winforms databinding uses something similar which often leads to exceptions being swallowed somewhere in controls while these exceptions really should have been left alone and be bubbled upwards. 

Which exceptions to catch and route to the event handler for example? All of them? Or just validation stuff? ASP.NET controls of some 3rd party vendors already are able to catch exceptions thrown by the bound datasource, which lead to a feature on our datasource control to throw an exception on invalid field input (e.g. "23abc" for a numeric field) which then could be caught by the bound control. Why isn't dynamic data using that mechanism instead? Now the datasource writer has to jump through hoops to add try/catch clauses everywhere to try to catch all exceptions. 

Furthermore, our datasource control for dynamic data is a subclass which implements specifics for dynamic data. I.o.w.: the main code isn't there, it's in our general datasourcecontrol. This therefore could lead to problems with this mechanism: code which is called by asp.net directly on the datasourcecontrol could lead to an exception but it's not caught and re-routed to the Exception event raiser because the code throwing the exception is in the general datasource control. 

So I don't see how this could ever work for 100%. 

Answer 6

User1641955678 posted

I will take this offiline with Frans to try to find a way to make this work.

thanks,
David

Answer 7

User320031091 posted

Hi David, any updates?

Answer 8

User1641955678 posted

Sorry Matt, I should have followed up.  I had a thread with Frans, and unfortunately things are not so simple.  In LLBLGEN, there is the base data source, and the derived datasource that supports Dynamic Data.  The derived one is easy to change and update, but the base one is not because it's part of the core framework.  Since solving this issue would require changes to the base, it may have to wait for the next LLBLGEN release.

However, I'd need to let Frans comment on his plans relating to this, as it is not something I can control.

thanks,
David

Answer 9

User-1938370448 posted

 The problem is mainly that to intercept an execption, a try-catch clause has to be added to the ExecuteSelect/Insert/Delete/Update methods, and those are in the general datasourcecode, in the datasourceview classes. The dynamicdata datasourcecontrol doesn't subclass those classes so can't override the execute* methods to add the try/catch. Creating a subclass for the datasourceview classes could work, however, the view instances are created by the datasource class (which is simply a wrapper for datasourceview classes which are the actual workers for datasource controls) and the current create routine isn't virtual nor really extensible (takes a couple of lines of code). The main problem however is: making these changes to the dynamicdata datasourcecontrol makes it dependent on a given build date of our runtime libraries which is pretty brittle, hence we can't make the change at the moment. 

I ignored the Exception event when building dynamic data support mainly because I found it such a bizarre event :) and didn't have a clue really what to do with it at that point. Anyway, you have to work around this problem one way or the other, I'm sorry. 

If you really want this, you should make the change in the runtime lib sourcecode and the dynamic data sourcecontrol class source.