Holiday reading update

I just had a look at the .NET Stock Trader sample application. Wow, it included some great features such as virtualization of service endpoints, a configuration management system etc. This stuff should considered when I develop my next distributed system.

On another note I have really started digging IoC containers like Castle Windsor. And LINQ to XML. The Entity Framework I am not too excited about and what I've heard about Oslo sounds like something from the MDA era and the reason why it failed.

For ORM-mapping I think my options today are (depending on project and complexity...):

NHibernate
.netTiers
d00dads

Rhino Mocks looks like a great tool too I think I will use it soon.

Powerful methods to consider in every project

IoC
Code Generation
AOP
Generics
GOF Design Patterns

Some nice technologies

i have come across lately

Balsamiq mockups. Awesome tool to create GUI mockups.

T4 code generator. Built into Visual Studio as of VS 2008

Naked objects. Generate GUI from database.

Null coalescing operator in C# 2.0 for ASP.NET ViewState property access

instead of

public bool Enabled
{
get
{
if(ViewState["Enabled"] == null)
return false;

return (bool)ViewState["Enabled"];
}
}

we can now write:

public bool Enabled
{
get
{
return (bool)(ViewState["Enabled"] ?? false);
}
}

Cool! But if we are dealing with a complex type i prefer defensive casting, using something like:

public ComplexObject Complex
{
get
{
return ViewState["Complex"] as ComplexObject;
}
}

Stepping it up with power tools

I bought a book called Windows Developer Power Tools and started looking for tools
to apply in a specific project. For this project I came up with the following:

Enterprise Library Block. To apply best practises within loggin etc.

NUnit 2.4.8. To have an automated test suite for some basic behavious such as object CRUD.

MyGeneration and custom templates. For generating manager classes among other things. ORM-code can be generated with dOOdads templates.

Caste Windsor Container. To promote reusability and get rockin things such as swappable business rules using Inversion of Control.

NDoc. To create professionally looking documetation.

CoolCommands. To improve developer productivity in VS.

VSFileFinder. To find files fast inside VS.

FxCop. To write code that uses best practises.

SourceMonitor. To manage code complexity.

NDepend. Find dependencies in your application that can be improved.

NTime. To verify that performance is acceptable for critical parts of the application.

NProf. To find out in which method time is spent.

Reclector.NET. To look into assemblies when documentation sucks.

Dotfuscator. To prevent reverse engineering of code.

Fiddler. To examinate HTTP traffic.

WSCF. To create contract based web services. Don't deal with the stuff VS produces out of the box.

Subversion. Source control.

AnhkSvn. Subversion in VS.

TortoiseSvn. Subversion in explorer.

Other tool not mentioned that I use:

YSlow. To find out how websites can be optimized.

XP IIS admin. To create multiple IIS websites in XP.

SelfSSL. To generate certs on localhost.


Now if I could just get my hands on a suitable AOP framework...

Improving ASP.NET code

I have an ASP.NET application that suffers from some problems.

We have a page that dynamically loads a lot of different components, and these components needs to access per-request properties of the application, such as user id, product name etc. Today this can be done something like:

string stateValueToGet = string.Empty;

// Coding horror..
// Component a is where stateValueToGet is parsed.
ComponentA compA = this.Parent.Parent as ComponetA;

if(compA != null)
{
stateValueToGet = compA.GetStateValue();
}

// do something with stateValueToGet ...

To begin with this is not good design to have components be dependent on each other like that. If the component should have a dependency it should probably only be to the page.

But alternative way to store these kind of per request values that need to be accessed in many different places during a page request is to use the HttpContext.Items property that allows you to store data as name-value pairs. However we should not access values directly from the Items collection but instead use proper C# helper classes or properties in the page class for that in order to hide validation, formatting etc.

One drawback with this solution is that dependencies among components will not be as clear but we should strive to minimize those anyway.

How to manage per-requst properties should be a core concern of the architecture.

In addition we need to handle session properties if those are used. Since session properties are used in a lot of different places these should be accessed using C# classes rather than properties in pages. An alternative way is to place these is a MasterPage or BasePage but i don't like that idea due to the fact that using this kind of inheritance can restrict reuse of components.