When you use .NET Remoting to communicate using custom objects between processes, you can suffer a performance penalty if you do not perform custom serialization on those objects.

Why? The default serialization is a generic implementation that includes all of the CLR type information for each object. This is needed to reconstruct the object on the receiving end of the remoting call.

This isn't a really big deal if you are only communicating single objects at a time and infrequently. This does become noticeable if you are returning custom collections that contain many objects or your application is really chatty.

Ok, so how do you improve the performance? Implement ISerializable on your objects and collections. It's a little tedious, but easy to do. Someday I may write an addin to do this work for me, but currently I use a code generator for my objects that includes this.

There are 3 things you need to do. In the example below, we are going to serialize the object as a byte[]. This serialization will be automatically called by the Remoting formatter when sending the object over the wire.

More...

Several years ago there was a big WTF moment for me when I read Frans Bouma's post refuting all of the claims people made for using stored procedures.

Jeff Atwood summarizes Fran's post here.

Every reason I had ever heard for using them over inline SQL was addressed. Ad-hoc (inline) SQL is brittle, it's easier to secure access to data in the database, and performance. The latter being the primary reason why I chose stored procedures.

I don't really have any arguments against their enlightening views. I'll even add to that the idea that if your database logic is in your database, you are tied to that database. It seems the general consensus is that a mixture of stored procedures (for specialized situations) and inline sql (for crud) is the way to go.

So why on earth do I still use stored procedures?

More...