CLR support in Yukon.

Stephen Forte predicts that some developers will fall into the trap of using a CLR language in stored procedures (and other such server-hosted objects) in Yukon.

I am emphasizing the "replacement for extended stored procedures" angle (almost exclusively) whenever I am discussing CLR support in Yukon.

The security aspects of CLR code running in Yukon is highly preferred over the risks of xp_'s.

I can see CLR code being used for some other specialized things, like aggregator and function objects, but how many of those do you write regularly, as compared to sprocs that are for data access and manipulation?

Bottom line: we should continue to use T-SQL for data-intensive operations and CLR instead of xp's, or for CPU-intensive operations, or accessing the .NET Framework.

Mike

1 Comment

  • I agree with you, but I also think that there may be other factors that will drive the use of the CLR in Yukon. PAG and some of the well-known authors will introduce some patterns for using the CLR that will become part of the common development practice for utilizing the CLR in Yukon. I expect to see some significant coverage of this on MSDN next year too.

Comments have been disabled for this content.