Given that System.Data.IDataRecord and System.Data.DataRow both share the following accessors:
IDataRecord Interface
object this[ string name ] { get; }
object this[ int i ] { get; }
DataRow public object this[ int columnIndex ] { get; set; }
public object this[ string columnName ] { get; set; }
When I'm building my DAL objects, I invariably have to build two constructors for my objects--one which takes the IDataRecord interface, and another which takes the DataRow object. The constructors are usually identical except for the type of the argument being passed to it. If a common interface could be extracted and shared between the DataReader and DataRow I'd only have to use one constructor.
I can see that the primary problem facing interface extraction is the fact that the DataReader is readonly, and the DataRow is read/write. The only way I see around this problem is if the compiler treated a read/write property as satisfying the Readonly condition of the interface. Or maybe we need a new scope term for Interfaces, such as "CanRead" and "CanWrite". A standard read/write property and a readonly property would satisfy the CanRead scope modifier. Likewise for the CanWrite portion. In other words, the Interface that whatever access level is given to the property, it must be Read-able, or Write-able, or both even.
Has anyone found a way around my core problem? What do you think the best way to solve it in future versions of the framework would be?
A while back I was trying to figure out why the Professional Editions of Office 2003 are required for end users of VSTO solutions. After yet another post in the newsgroups on this question, I finally got this reply from Microsoft:
VSTO requires XML support within Microsoft Office and only the Professional
Editions of Office 2003 and the standalone editions of Microsoft Word 2003
and Microsoft Excel 2003 provide the XML support required for VSTO.
At least end users can buy the stand-alone versions of MS Word and Excel if need be, but I sincerely hope that the XML support mentioned (still not sure how the XML support relates to VSTO, but I'll take their word for it for now) makes it into the Standard editions of future releases, as that is what most companies purchase for most of their employees. I like working with Office documents in .NET, but if VSTO is going to be a viable technology, the end user requirements are going to have to be more affordable.
I bought a house near where I work. There aren't a lot of dev jobs available in this city, so I guess I'm making a commitment to my company :-). Things are pretty good here. I have a lot of creative freedom and we've starting using Agile development methodologies such as TDD. We're getting a continuous integration build server set up as well. In addition I get to work with my favorite development environment (.NET of course!), and I am consistently challenged to improve my skills in a wide range of areas.
I think I'll be happy here for awhile. :-)