Reflection instead of Interface?

LParker posted on Monday, June 15, 2009

Is there a particular reason that CSLA uses reflection to access the DataPortal_XYZ methods?  If I rename DataPortal_Fetch in my business object, I get a runtime exception.  Obviously I shouldn't be doing this, but it's a private method which would lead me to think that I can call it whatever I want (although how else would CSLA know about a private method except via reflection).

Why doesn't the framework use an interface or overrides of protected virtual methods to get at these data access methods?  You'd get the advantage of compile-time checking, and I would think it would be much faster than reflection as well.

-Larry

ajj3085 replied on Tuesday, June 16, 2009

Probably because the interface would have to be public, thus allowing anyone to call the DP_xyz methods... say for example your UI developer.

That pretty much goes against everything Csla is built upon. So while it's true you'll get an exception, you'll get a known exception that tells you exactly whats wrong. Every framework has its own set of rules that you must follow, or your use of the framework will be a failure. This is one of those rules.

As far as reflection goes, data binding uses reflection much more extensively than Csla, and no one is saying to avoid using databinding because it uses reflection. Also, the network hop will be your largest performance bottleneck; reflection is cheap by comparison.

LParker replied on Tuesday, June 16, 2009

Well I certainly wouldn't want to go against everything that CSLA was built upon. 

It seems that interfaces / protected methods could probably have been used with some other security mechanism, but if reflection was how it was done, then so be it.

 

ajj3085 replied on Tuesday, June 16, 2009

Well that's a good point, but I think the hiding is just one reason.. after all, a UI developer could also use reflection to call the method... but part of the goal is not to make it simple. :-)

Also, consider this. You can have multiple create or fetch factory methods, which may have different Critera objects passed. So one DataPortal_Fetch might expect a SingleCriteria, another my expect DataPortal_Fetch( MyCustomCriteriaClasss ), etc. Virtual methods or interface definitions wouldn't be able to define every possible type that a DataPortal_Fetch might take. So maybe that's a better reason. :-)

JoeFallon1 replied on Tuesday, June 16, 2009

In addition to what Andy said, this topic has been brought up before. A few times in fact. It was heavily debated and Rocky answered it in depth. I just can't recall the specifics this far down the road!

Joe

RockfordLhotka replied on Tuesday, June 16, 2009

First, CSLA doesn't use reflection to invoke those methods, it uses dynamic method invocation (starting in version 3.5), which is nearly as fast as normal method invocation and is much faster than reflection.

The two primary reasons for not using an interface are

1. An interface would need to be public, and so would allow code to mis-use the methods too easily
2. More importantly, you'd lose the method overloading feature that exists now, and you'd have to do your own casting and method routing - which people used to have to do and it was a pain

 

LParker replied on Thursday, June 18, 2009

Thanks all -- I appreciate the quick responses!