A Vector Type for C# - CodeProject

The other day I was looking for a Vector class for a C# project. I was actually wanting a 2D vector, but I've come across a 3D one which is great, so, recommended:

A Vector Type for C# - CodeProject

Customize Keyboard on Microsoft Word

This one is quick and simple, but as obscure as hell:

In Microsoft Word 2010 (probably 2007 as well), hold CTRL-ALT-+ to have your cursor turn into a kind of crosshairs. Click in whatever button you want to assign a button to, and the Customize Keyboard dialog will appear.

This obscure, undocumented feature saved my life once.

Solid (object-oriented design) - Wikipedia, the free encyclopedia

This is a "note-to-self". While mainly overlooked by many official computer science courses and graduations (mine included), Solid is a very important principle to apply to projects.

It should be standard practice to test every software implementation against it.

I'd turn it into a rule-of-thumb, if possible. After designing the domain classes, check for SOLID. After finishing every release of the product, check for SOLID. Nice and smart!

DTO vs. POCO

This should have been clear enough. DTOs and POCO are two different things. If, by some reason, you are as confuse as I have been:

- Data Transfer Objects are objects that only have data (properties, if we are talking about C#) and, sometimes, logic to retrieve that data.

- Plain Old CLR Objects are objects that are simple -- they have simple logic to represent a real world object. They do contain methods and stuff.

I got them both mixed up some time ago (actually, a long time ago) when designing an architecture. It took me at least an year to discover that, while similar (POCOs may look like DTOs), they weren't the same. You see, I decided not to attach any logic to my POCOs, and I thought that it was "compliant" with this design principle.

Now I was reading some stuff over the matter and remembered to post it here. Someone might make the same mistake.

Validation Application Block Warts

As you all will have noticed from my previous post, I'm digging deeper with VAB from Enterprise Library (4.1, not 5, by-the-way). The reason for choosing VAB as my validation framework was simply the fact that I could, by using it, remove all notion of validation from the Model classes and stick it into a configuration file.

This serves two purposes:

1. On a multi-tier architecture, I could make sure presentation tiers had no access to validation structures but still use the validation classes, because the validation configuration would be deployed only at the back-end, where my BLL resides.
2. I could lookup all messages being issued by my application on a single file. Of course this would be possible by using Resources, but that is a lot of work when not planning to localize the application.

So I delved into VAB during the last couple of days. Only to get myself disappointed.

Don't get me wrong, it's still a nice framework, but the two reasons above are linked to storing the validation rules in external configuration files. And that fails miserably because VAB won't validate ancestors rules when using configuration files based validation. 

The workaround for that is to replicate every rule for an ancestor at the derived class. Which is not a real solution, since such replication will lead to errors quicker than you can say "what". 

I think this defeats the purpose of using configuration files. VAB is a choice only when dealing with complex system, and on such systems, there probably will have at least some cases of inheritance.