May 2009 Entries
I’m generally against code generation for a variety of reasons I’m not going to talk about here. However in some cases, small, targeted code generation is good, as it helps you avoid repetitive typing in verbose languages like C# without creating unmaintainable blob of poor quality code. In other words, I very much like being able to go from this: to this: by just pressing Enter.
Not that I’m proud of that, but to circumvent the limitations of CLR and C# I sometimes had to use reflection, code generation, changing behavior depending on who’s calling etc.
However I think this code beats all that.
public static class HandleProvider
{
private static int _currentToken = typeof(object).GetConstructors()[0].MetadataToken;
private static ModuleHandle _moduleHandle = typeof(object).Module.ModuleHandle;
/// <summary>
/// This is an ugly hack to circumvent lack of useful public constructor on RuntimeMethodHandle struct
/// </summary>
/// <returns>Method handle of some method from mscorlib</returns>
...
There comes a time when you have to store in the database not only pretty objects but also some not so pretty data. For example, let’s take the classical entity – the invoice. Let’s say your application can receive invoice in three ways: by its own frontend, by email in rtf file, and by fax. In two later cases you may have a requirement to store the rtf file and the scanned fax as a proof in the database. How to approach that? Let’s start by sketching our Invoice class: ...
As nice as the example from my previous post was (person having pets) it exhibits a problem. The problem is related to the fact that by their very nature associations in relational databases are bidirectional, whereas in objects they are unidirectional. Here we hit the mythical impedance mismatch.
Often however we want to have a bidirectional association in our object model. Person may have a set of pets, but then each pet has its owner. Then we have another problem. What if we add a pet to person’s pet collection, but forget to set pet’s owner? We’ll get inconsistencies.
The best way...
I’ve been working with NHibernate for the last couple of days, and as I make my way though it, I find out about things, that were not so obvious to me at first, so I decided to post them here, so that someone else can benefit as well. First thing you learn about NHibernate (well ok – first thing I learned about NHibernate, but most of you probably as well) is that it requires you to mark your properties virtual, have parameterless constructor, and pay special attention to your GetHashCode() and Equals() methods. With all...
As I hinted in my previous post, here comes another release from Castle Land. This time it’s Castle Windsor, No more – “we’ll not use a two year old prerelease software.”. Ayende has all the details, so I’ll just say that if you’re still using RC3 there’s a lot of new good stuff waiting for you. Congratulation to Ayende and the whole Castle Team. Grab the bits here.
Final version of Castle Dynamic Proxy 2.1 is officially released as of today. For the announcement see Jonathon’s blog. This is the first release since the split of monolithic Castle Project into independent projects. It also opens a way for all other projects depending on Dynamic Proxy to get a release (some of them will be released very soon). Also I want to remind you of Castle UserVoice site, where you can suggest features and improvements you’d like to see in the next version. Not only for DynamicProxy, but for any project under Castle umbrella....
I’ve been doing a lot of work with WCF lately. It’s a great framework, and I really like it, but it has its drawbacks. First of all, it is overly complicated in certain places (security!), which makes it really hard to use sometimes. Its sheer size, makes it also hard to grasp. It has a lot of extensions points but the fact that you have to plug into them yourself adds to that complexity. It simply begs for good IoC integration.
You can partially alleviate that by using Castle WCF facility that lets you use IoC container to extend WCF, but...