How many developers do you know who can write solid SQL queries? Practically every developer knows SQL, but there aren't too many who know how to use it well. Now don't get me wrong, i am by no means a SQL guru... but i like to think i can hold my own when it comes to writing 'good' queries. With the advent of querying techniques that shield you from directly using SQL (like the LINQ syntax, or NHibernate's Criteria) the number of developers with solid SQL knowledge will probably only get smaller and smaller in the coming years. I wonder if in 5 years time, developers with good SQL skills will be as rare as politicians that don't take money, athletes that don't use performance enhancing drugs, doctors who care about your health instead of their wallet, gangsta rappers who actually used to be 'gangsta', single women that don't... well, i'm sure you catch my drift.
Pretty soon, most .NET developers will be using nothing but LINQ statements to query their databases. Obviously, a part of the problem will shift from lousy SQL statements to lousy LINQ statements. That's pretty much unavoidable, given the ratio of 'bad' developers out there. But the productivity gains from using LINQ (or Criteria) over directly using SQL will probably become more and more important as time goes on. Not to mention the fact that LINQ is 'sexy' and will be pushed heavily by Microsoft.
Would that actually be a bad thing though? I kinda think the situation is similar to the shift we've seen over the years in programming languages. We used to write code in assembly language. Well, 'we' didn't, but the poor souls who were in this industry before us did. Then people moved to higher level languages (like C) for the increased productivity. Fast-forward a couple of years and people moved to development platforms where the actual code would be compiled to machine code 'just-in-time', at runtime even! Oh, the horrors!
In each and every one of those shifts, there were developers who said "i don't care, my hand-written code is definitely gonna outperform that". And at the beginning of those shifts, this was probably true for a lot of developers. But as time went on, the newer technologies pretty much always 'won' because of the productivity gains. Even if they were slower in direct comparisons. Then again, those technologies evolve as well and they usually get faster along the way. The runtime performance of current Java byte code is a lot better than it was in the first 3 years that Java was around. I'm not sure if the .NET runtime has actually gotten faster in the past couple of years, but then again, it probably picked up on a lot of lessons learned in the Java world before .NET was released.
One thing that has happened consistently is that compilers have always gotten better. Well, they've always gotten better at optimizing the code they generate. This leads to situations where the same code actually runs better when it's compiled with newer versions of a compiler (well, if it still compiles...). Obviously, this isn't true for all code, but it usually is true for certain statements, or certain frequently-used bad-performing techniques (string concatenation for instance).
I wouldn't be surprised to see the same thing happening with LINQ providers (or other SQL querying abstractions for that matter). The SQL that is generated by them is pretty good already. And it's never gonna get worse... they will always become 'smarter' and they will generate better SQL statements in future versions. When that happens, we all benefit from that.
Sure, there will always be die hard SQL fans who keep writing their own SQL queries and there will always be edge-cases where hand-written SQL queries will be better than those generated by higher level libraries. Especially if those SQL queries were written by Disco Stu. I mean SQL Ben (laugh Ben, it's just a joke 
). But i do believe that will only be true in edge-cases.
A coworker of mine, Tom Ceulemans, has provided a very nice solution to the mocking dilemma i posted earlier. I like this solution so much, i think it deserves its own post 
The original question was basically: how do you do access a protected member in a test? I didn't want to make it public because it is a base class, and i was hoping to avoid making it protected internal and then exposing the internals to my tests assembly.
Tom's solution is very nice, and IMO, very clean as well. The trick is to create a derived abstract class from the class you want to test and then write the TestFixture as an inner class of the newly created class.
The test shown in the previous post would now look like this:
public abstract class MyAbstractClassTestWrapper : MyAbstractClass
{
[TestFixture]
public class MyAbstractClassTests
{
[Test]
public void CallsProtectedAbstractMethod()
{
var mocks = new MockRepository();
var myObject = mocks.DynamicMock<MyAbstractClassTestWrapper>();
myObject.Expect(m => m.DoSomethingSpecific()); // <= no more compile error
myObject.Replay();
myObject.DoSomethingInteresting();
myObject.VerifyAllExpectations();
}
}
}
I like it
Manually dealing with KnownTypes in WCF is a bit of a pain. Well, at least if you have more than a few derived types you want your WCF services to serialize/deserialize. Luckily for us, there is a way to do this automatically. Using the ServiceKnownType attribute you can specify a class and a static method of that class which will provide the Known Types. An example of this can be found on my ever-recurring Process service method:
[OperationContract]
[ServiceKnownType("GetKnownTypes", typeof(KnownTypeProvider))]
Response[] Process(params Request[] requests);
This works, but i don't want to write a class every time i want to specify some known types of a base type in a service method. So i modified that KnownTypeProvider class so that we can now do the following:
KnownTypeProvider.RegisterDerivedTypesOf<Request>(mySharedAssembly);
KnownTypeProvider.RegisterDerivedTypesOf<Response>(mySharedAssembly);
This registers each derived type of Request and Response in the mySharedAssembly reference (of type Assembly) with the KnownTypeProvider. You can register as many known types for as many base types as you want. Obviously, you have to do this before you start hosting your service. You also need to do this client-side, before you start using your service proxies.
You're probably thinking "wait, won't that return all registered known types for every service call where you use this stuff?". That wouldn't be good, so i took care of that. The ServiceKnownType attribute of WCF requires your class to implement a method which receives a parameter of type ICustomAttributeProvider and which returns a list of types. The ICustomAttributeProvider parameter is actually a MethodInfo instance at runtime. This makes it possible to inspect the current service method's parameters and return type. That information makes it possible to only return the KnownTypes that are relevant to the current service call. All of this sounds expensive with regards to performance, so obviously this is all cached... so you only take the performance hit on the very first request of each service method where you use this.
The KnownTypeProvider makes it extremely easy to register your KnownTypes in a generic way, can be reused across multiple service methods and it only returns the relevant KnownTypes for each service method. And it does so with a minimum of performance overhead.
You can find the code in my public svn repository as a part of my utility library (the tests can be found here). At this moment it is one of the only classes in the library, because i still have to add some other stuff before i'll put a 'proper release' online
Some of the stuff i've posted here lately seems to be somewhat popular and i'd like to make those things available to anyone who wants to use them. Scraping code together from blog posts is not only an annoying job, it's also not entirely legal due to no explicit license being mentioned. So because of this, i've decided to just make this stuff available in a utility library with the intent of making everything easy to (re)use 'out-of-the-box'. This library will be BSD-licensed so you'll have a couple of options if you want to use it or parts of it...
The two biggest things i'd like to make very easy to use are of course the whole WCF batching stuff, and probably some base classes for my testable ASP.NET webforms. There will be a couple of smaller, yet interesting parts in there as well though... My KnownTypeProvider class from the WCF batching article also received some interest so i'm going to add that in a more reusable way as well, without it having anything to do with the whole batching issue.
I'm still assembling the various parts and making some modifications/improvements along the way, so i'll probably release the code somewhere in the coming week, depending on how much time i'll have to work on it.