18 November 2005

I’ve posted a couple times before about what a business class will look like in the next edition of my

business objects books and thus in CSLA .NET 2.0. One of those times Jason Bock (a fellow Magenicon) sent me an email asking why the DataPortal_Create/Fetch/Delete methods aren’t strongly typed.

<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /> 

If you look at the current approach and what I’ve posted thus far for the next edition you’ll see code like this:   Protected Overrides Sub DataPortal_Fetch(ByVal criteria As Object) or protected override void DataPortal_Fetch(object criteria)   Jason’s comment got me thinking. The DataPortal uses reflection to invoke this method, so why not be a bit more thorough in identifying the method’s parameters and invoke a strongly typed version like this:   Private Overloads Sub DataPortal_Fetch(ByVal criteria As Criteria) or void DataPortal_Fetch(Criteria criteria)   Where Criteria is the actual type of the criteria object provided when calling the DataPortal.Fetch() method back in the factory.   (the Overloads keyword is required because the base class still implements the default protected version)   As with many things, this sounded relatively trivial but turned out to be somewhat harder than expected. It is always the edge cases that make things hard… In this case the hard part is that parameters could be Nothing – in which case you don’t know what type they would be if they weren’t Nothing...   After working through that issue all is well.   This (in my opinion) is better than the alternative, which was to go with an interface-based approach and formalize the late-bound concept. That has its attraction, and people have altered CSLA .NET 1.0 along that line, but I really prefer strong typing if I can get it.   In particular this is nice for collections, where you may have multiple criteria classes for different views – now you can just implement a strongly-typed DataPortal_Fetch() method for each criteria class. Very clean and nice.   I’m still deliberating over whether to leave the default protected implementations in the base classes. They are nice because VS helps you override those methods, but they aren’t optimal. Given that VS has such nice snippet support it may be better to drop the protected defaults and just rely on snippets to insert the DataPortal_XYZ methods.   If you have an opinion, feel free to comment :)