Month: January 2010

One of the things that was in AutoGen from version 0.001 was the ability to intercept Dispose.  This might seem like a relatively minor concern, but it was actually central to the design.  First the bad news: after a lot of work, the Dispose functionality still had edge-case failures.  The truth is, the lifestyle aspects of Windsor are quite complex, and any Dispose interception implementation needs to understand it completely.  So why did I bother?  And why is Krzysztof bothering now?

We need to return to one of the basic principles of IoC containers: the code being hosted shouldn’t need to know it’s being hosted.  It’s this design philosophy that sets it apart from EJB, ASP.NET and any number of other hosting technologies.  The release method violates this badly.  Even if you hide the container behind an abstract factory it’s not good enough: you’ll need to add lifecycle concerns directly to the factory interface.  Windsor provides an API for releasing resources that goes against the grain of .NET development.  If you create an object in a using statement and it goes out of scope, you’ve got a reasonable expectation that you’re done with that object.

Container independence may not be a concern to many, but it breaks that too.  Every abstraction that sits on top of Castle has to know about this detail or it will end up leaking instances.  It pretty much breaks the Common Service Locator: there’s just no sensible implementation of it that doesn’t involve providing a footnte saying “I hope you remember to call IWindsorContainer.Release at the appropriate times.”*

Does it matter?  Well, like all resource leaks, it depends.  But in certain circumstances, it will. 

What can we do?

Intercepting IDisposable isn’t ideal either; for a start, you’d need to proxy absolutely everything that implements IDisposable to get it to work.  There’s a couple of other alternatives I can think of here:

• Leave it the way that it is and pretend it’s a user problem.  (You may suspect I don’t favour this option.)
• Remove the functionality that requires Windsor hold the reference.  (This might be easier said than done.)
• Start holding onto transients using WeakReferences.  (Ditto)

UPDATE: Krzysztof has pointed out that the WeakReference proposal may be a cure worse than the disease, since it relies on Finalizers to work.

*Some readers may object that, even if releasing individual instances is relatively hard, you can always get rid of the lot by disposing of the container.  This would, of course, assume that your factory implemented IDisposable, which sadly the Common Service Locator doesn’t.  Siege, thankfully, does, so it’s at least possible to do that if you’re using Marcus’ code.

Technorati Tags: Castle Windsor,Container Independence,AutoGen

One of the most frustrating things for a user is to receive a cryptic error message.  This is closely followed by a developer receiving the same error message.  Let’s say you’re using Fluent NHibernate and you get the error message “Sequence contains no elements”.  Chances are, you’ve done something wrong.  The problem is that you’re not going to figure out what unless you actually debug the source code.  This particular error message is generated by the “Single” extension method.  This code by design does the following:

• Returns the first element in the list
• OR Generates a cryptic error message

There’s no sensible way to use the function short of putting a try/catch/rethrow around every single invocation.  You couldn’t even recode the function to be more helpful: there’s simply no useful information provided to it.  Basically, there’s no way Single (or First, for that matter) can be used in high-quality code.  SingleOrDefault and FirstOrDefault, on the other hand, have a way of dealing with failures that doesn’t involve cryptic errors messages (you can still throw an exception, and that can still be cryptic, but then it’s your fault, not Microsoft’s). 

How else could we have designed this API?  Well, we could try “First(Func<Exception> onError)”.  This would be fine for First, because there’s only one failure mode: there’s no elements in the list.  However, for Single there are two possible failure conditions: no elements and multiple elements.  Do we add in two onError functions or do we create a Problem input?  And then should we be using Func<Problem, Exception> or going for the general stable case of ProblemVisitor?

The answer is probably that the last case doesn’t come up: if you’ve got that complex a spectrum of failure conditions, you’ve probably provided the code with enough inputs to generate good error conditions.  However, even in fairly general cases, sometimes you need to pass information to a function purely to improve the diagnostics.  On the other hand, functions like First, Single and Parse (TryParse is okay) will never have good diagnostics are pretty much impossible to use in easy to debug code.

Let’s just give you the punchline of the post first:

If you’re trying to access the file “ftp://somehost/somedirectory/some.filename” and you’re getting a 550 error, you need to change the Uri to “ftp://somehost/%2f/somedirectory/some.filename”

You can find more details on Mariya Atanasova’s Blog.  OK, now that I’ve performed the public service, let’s explain why this works. 

FtpWebRequest interprets every directory in the chain as a “CWD” command (CD in DOS terminology).  Each of these is relative to the previous location.  The first location is wherever the FTP server dumped you on logon.  A behaviour that is irritating in interactive mode is made just plain unusable as an API.  What’s worse, Microsoft have actually implemented the spec correctly (section 3.2.2 if you really care).  This basically means that FTP urls don’t work the way you expect and don’t behave in a similar way to HTTP urls.

So, to fix this, we need to first change to the root directory.  That, of course, means executing a “CWD /” command.  Of course, since / is a special character in the URL syntax, you end up having to write “%2F” to trick the FtpWebRequest into doing the right thing.  Ultimately, the moral of this story is that FtpWebRequest and ftp URIs are the wrong model for interacting with FTP.  I can’t see that being changed anytime soon, however.

I have to admit, when I read Uncle Bob’s post about dependency injection, I really didn’t expect the response it would get since it struck me as being relatively uncontroversial.  So Davy’s reaction rather surprised me.  Davy had two major objections to the original article:

• The contention that IoC containers aren’t always appropriate.
• The advocating of the use of abstract factories.

Now, when I teach constructor injection to developers around my company, I always teach it in the manner Uncle Bob describes: just pass things into the constructor.  Sooner or later someone asks where things come from initially, and I explain that it all gets set up in the main method.  Let’s revisit why we’ve done this: we’ve separated stable code from unstable code since we’ve moved the wiring into the main method.  IoC containers are all about configuration.  If your configuration isn’t complex, I don’t particularly want to confuse a developer by introducing the concept.  I usually let them hit the point at which wiring has become painful and then show them the next step.

Don’t get me wrong, I love IoC containers.  They’re power tools and I wouldn’t do without them on complex projects.  But not everything I write is that complex, and I wouldn’t use an IoC container for Solution Transform any more than I would use an electric drill on an Ikea table; the likelihood of woodchips flying everywhere is just way too high.

Charlie and the Abstract Factory

A point that I don’t think is made enough is that the SOLID principles aren’t just about what, they’re about where.  Dependency Inversion, however you practice it, moves your externalities into one place: the Main method.  However, Uncle Bob’s second point is about location as well.  Now, I don’t think many people in the .NET world are still using attribute-based registration but the fact remains that it does cause your entire code to take a dependency on your container.  If you and every possible client you can envisage uses that container that’s not the end of the world.  The same argument applies to any invariant dependency.  For anyone else, it’s at best rude and quite likely to lead them back into the kind of configuration hell IoC is meant to avoid.*

As I understand it, the main objections to the abstract factory concept are as follows:

• They will result in a lot of abstract factories.
• The factories will be dependent upon the container.

I think the first problem is overstated.  As Davy says himself, the constructor injection behaviour of the container ensures that most resolution is handled seamlessly.  When would you actually need to use container resolution?**

• In the main method. 
• Where you need to create multiple objects of the same type.
• Where you need to dynamically create different implementations for the same interface depending on your current state.

The first isn’t a problem, you’ve already got a hard dependency on your container there.  It’s the other two where you need an Abstract Factory.  Here, you’ve got three choices again:

• Write a dedicated implementation that doesn’t use a container at all.  This is the classical (GoF) understanding of how to implement the pattern.
• Use your container’s resolution API
• Hide your container behind an Adapter pattern.

I’d argue the first approach can be appropriate, but may be a code-smell in code that uses an IoC container.  It indicates you’re not really happy with the resolution behaviour of your container.  On the other hand, nServiceBus takes the last approach with the IBuilder interface and implementations.  Davy’s own Agatha does something similar.  However, these are slightly misleading examples since they’re still phenomenally general.  If you’re throwing an interface that general around your code, you’re either writing a framework or violating the Interface Segregation Principle. 

You are in a Maze of Twisty Principles, All Alike

Imagine if whilst reading the Gang of Four book, you were told that the correct maze factory implementation was this:

public interface IGeneralFactory
{
    TResult Make<TResult>(IDictionary<string, object> parameters);
}

Rather than this:

public interface IMazeFactory {
    IMaze MakeMaze();
    IRoom MakeRoom(int id);
    IWall MakeWall();
    IDoor MakeDoor(IRoom room1, IRoom room2);
}

The latter code communicates intent and limits the interface to the operations the client is going to need.  The former is overly general and its purpose could be anything.  It’s so general it would be pretty impossible to simulate, which quickly leads to the “containers in tests” anti-pattern.  Unless you believe that there’s something magical about inversion of control containers that make standard design concerns go away, you’re going to be favouring the latter interface in your code.  Moreover, by putting the maze factory interface with the library which consumes it and the implementation with the registration code (which is container specific) we’ve remove all of our dependencies in our library code on the framework.

Uncle Bob’s example isn’t really helped by the fact that it doesn’t scale.  Although perfect for mid-sized apps with relatively few requirements for dynamic resolution, in practice you’re more likely to implement the factories as taking a container as a dependency, with a similarly modular system for the registration of components.  (Krzysztof has already remarked that .NET containers seem to have better tooling in this regard, but the principles apply either way.)  However, the classes are still coupled, and should be located in the same assembly.**

Removing Tedium

This last part isn’t really about coding principles, but let’s take this further.  There’s an unspoken third objection to using abstract factories religiously: that the code is dull and repetitive.  It bulks up our registration code with form-filling noise.  Wouldn’t it be better if you could just inject the interface into your container and have it auto-generate the implementation class for you?  This would shorten your registration code, keep the complete lack of hard dependencies on your containers and generally make your code shorter and more flexible.  Well, that’s the point I reached a year ago with AutoGen.  Castle Windsor had a crippled implementation at that time, but it’s usable these days.

Seriously, would you rather:

• Take a hard dependency on your IoC container throughout your code.
• Write “Component.For<IMazeFactory>().AsFactory()”?

Not all containers expose this functionality (I’d argue that most should) but that’s not a problem.  You’ve still got the technique Uncle Bob describes to fall back upon.  If more did, we’d be a lot further along the road to container independence than we are now.

*I could expand on this point further, but I’m not convinced anyone is likely to contend with what I’m saying here.

**I’ve used the terms “resolve” and “assembly” throughout here, because I’m a .NET developer.  However, the argument doesn’t noticeably change if you say “getInstance” and “Package”.

UPDATE: I’ve tightened up the style at points to improve readability. Semantically it’s unchanged.

UPDATE 2: Jeffrey Palermo made a comment to the original post which said “[We are] lying to ourselves […] that it is not a global and that it in itself is not a dependency”. He then followed it up with a post which ended up proposing a poor man’s IoC as a global variable. As I’ve said before, I don’t agree with approaches like this.

UPDATE 3: Oren posted a counter-example to the idea about manual constructor injection. He seemed to be arguing that just because you couldn’t write expedia.com that way you shouldn’t try to do so for smaller programs. In particular, two things about his example aren’t shown on the diagram: the need for lifecycle management and the presence of more than one controller. A straight console program that required that set up would probably be better written just using manual injection.

UPDATE 4: Davy posted a response to this article that makes it clear that we’re actually pretty much in agreement as to best practice (although he doesn’t have the tooling that’s the final step in the article). I now think that his principal objection to Uncle Bob’s factory code is that it puts registration and resolution into the same class, which I agree doesn’t scale. There’s another case of “container as global variable” in his code, but I think I’ll work that into a separate blog post.

(Incidentally, one major objection to putting registration and resolution into the same object is that it violates SRP. However, that argument would also apply to the container itself.)

UPDATE 5: Uncle Bob followed this up with a similarly back-to-basics post about mocking frameworks. Again, his emphasis is on how the principles are independent of the tools, and that the tools are sometime overkill. However, I think I’m going to sit this one out. 🙂

Most people reading this blog probably had to take a Christmas tree down in the last month.  Now, my Christmas tree is a pretty cheap plastic one I picked up at the local supermarket and requires some assembly.  This got me thinking about the lean concept of process flow.  Let’s analyze what’s involved in getting the tree put away for next year:

• I have to take the branches off the tree
• I have to “un-spread”, or flatten, the branches.  This involves me gathering all of the sub-branches together and twisting until they stay together.
• Finally, I had to put the branches in the box.

Now, in manufacturing one of the principal sources of waste can be transport and storage costs.  Obviously, storage isn’t really going to cost me anything: I can just drop pieces on the floor.  On the other hand, transport can be an issue: it’s easy to drop pieces on the floor, but picking them up involves bending down and I’d rather minimize that.

Now, Lean Thinking will tell you always to concentrate on making processes flow.  Here’s how that would look:

• Take a branch off the tree
• Flatten it
• Put it in the box

There’s two difficulties in practice with that approach, and both are related to the final step.  First, certain pieces need to go in first or it’s unlikely you’ll get them all to fit.  Those pieces are large and at the centre of the tree.  In other words, they’re the last pieces you get hold of taking branches off the tree.  Another is that, actually, it’s much easier to put in five small pieces at a time than five in a go.  (There’s another alternative here I’m not going to examine: take the box apart, put all the pieces in it and then use gaffer tape to stick it back together.)

So, now I’m flattening everything before putting it into the box.  So, is process flow not working for me?  Not quite.

The Whole Value Chain

The first step of lean thinking is to analyze the whole value chain.  Now, value for me is defined as getting all of the Christmas stuff put away.  So far, I’ve only been considering the tree.  Let’s just add in the lights on the tree to the value chain.

Now, I’m very fond of my Christmas lights, but they’re a series of large (5cm) baubles connected by wire wrapped around the tree.  A tree which is, itself, pretty physically complex.  They catch everywhere.  Taking them off is a pain in the neck and needs to be done before you start disassembling the tree.

Actually, no it doesn’t.

Here’s what you can do: find one end of the lights and pull lightly.  Identify the branch on which it is caught and pull the branch off and leave it on the floor.  This has the entertaining property of making it significantly easier to take the lights off and doing a fair proportion of the next step.  You can then

• Take the remaining branches and flatten them before dropping them on the floor as well. 
• Sit down and flatten the remaining branches
• Put the whole thing in the box.

This is definitely improved, but the two stage flattening looks inelegant.  I can’t flatten the branches while I’m taking off the lights because my hands are already occupied.  But what would have happened if I’d added the rest of the tree’s decorations into the analysis?

Here, we’ve got another process improvement.  Removing the branch and then removing the decorations from it is probably easier than removing them from the fully assembled tree.  The lights would then be easier to remove.  Finally, it addresses all of the branches, making it possible to flatten them straight after removing the decorations and re-introducing some of the “flow” we lost when we realized the boxing was a batch step.

Why didn’t I do that?  Simply, that bit was done by my wife and I wasn’t involved at that stage.  Again, we’re seeing another aspect of lean thinking here: to correctly optimize the process flow, I can’t just concentrate on my part of the job, I’ve got to look at the whole enterprise.  Of course, that’s easier to achieve when you’re part of the same company (or marriage) than otherwise, but often that’s where a lot of benefit can be found.

So, what have we seen here:

• Making processes flow is desirable, but there are cases, such as packing the branches, where it doesn’t work.
• The more steps in the value chain you include, the more likely you are to come up with an optimal solution.
• Communication with other producers in the value chain can revolutionise the process.

You might be wondering why I tackled single responsibility last rather than, as is more conventional, first.  Partly it’s because I simply found it very hard to write about, but I think it goes deeper than that: it’s actually very hard to understand, partly because of the perspective issues it raises.  There’s no one right answer to how to observe SRP.

The official statement of the principle is “A class should have one, and only one, reason to change.”  It’s not clear to me that “one reason to change” is any better defined than “single responsibility”.  As I’ve said before, it’s fundamentally a naming problem.  Academic studies on functional cohesion focus on coming up with better metrics.  Given that no-one’s developed a decent metric for evaluating a method yet, I don’t think this is going to be fruitful. 

However, I think it’s worth looking at the single responsibility principle and seeing how it interacts with the other SOLID principles.  From the perspective of the interface segregation principle, it basically looks like a generalization.  Not only should your interactions be small and well defined, so should your implementations.  Like the ISP, it makes observing Liskov easier.  The fewer things a class does, the less likely you’re going to need to break Liskov to get a subclass to do what you need.  Equally, it’s less likely to need to change, so it makes it easier to observe the open closed principle.

The story gets even more interesting when you look at dependency inversion.  The smaller your objects, the more you’re going to have to throw around.  Again, you probably need facades on top of these single responsibility objects to simplify interactions.  Providing a facade is a responsibility in its own right.*  However, just as Liskov makes inheritance work, Single Responsibility makes pluggability work.  The smaller classes need to be changed less often, and are easier to swap out for alternative implementations.

So, where do we go next?  Well, the Open Closed Principle lead us to refinements, where we came up with techniques to ensure it such as constructor injection and Liskov.  Equally, since we have an issue of naming here, it can help to standardize naming in some way.  Luckily, we have a fairly large catalog of standard names to begin with in the shape of design patterns.  e.g. Abstract Factory, Repository, Presenter

*Or to put it another way: eventually you’re going to need a car object.

I can’t be the only person who has been frustrated by the inflexible nature of Visual Studio solutions and projects.  So when Krzysztof asked for someone to write a program to convert vanilla .NET projects to Silverlight projects, I jumped at the chance.  Of course, I then proceeded to take four months to deliver what is, in all honesty, a fairly simple piece of code.  Anyway, it’s finally checked into Castle Contrib at https://svn.castleproject.org/svn/castlecontrib/SolutionTransform/trunk/.

Ironically, I’ve already blogged about the basic architecture, although the code is now a bit more complex than the braindead example I was running with at the time. I make BOO do the work.  Basically, the code goes through the solution and filters out projects.  It then applies transforms to the projects and (optionally) the underlying code files.

You call it as follows:

SolutionTransform <<Name of Script>> <<Full Path of Solution>>

There’s only two scripts so far (in the scripts folder).  One standardizes code files for the Castle Project, the other converts castle vs2008 projects to Silverlight 3.0 projects.  This second has been the whole point of the project .  It’s the missing piece of any plan to develop a class library for regular .NET and Silverlight simultaneously.  Without something like this, it’s a complete pain to keep the versions in sync.

The Challenge

You’ll find there are exactly four tests at the moment.  I know what some people are going to say about this, but the truth is the expected end result hasn’t been very well understood until quite recently.  This was, in fact, the principal challenge in writing the code.  Krzysztof had to throw several versions back before I checked anything in.  It looked like it would work, but it didn’t.  Writing extensive tests wouldn’t have helped: the tests would have been wrong too.

The nature of the project is that I’m pretty much guaranteed that there’s going to be a wall of edge cases.  I’ve spent a month with something that looked stable except for one show-stopper.  (I’ll blog about that soon.)  Neither of these file formats is exactly documented.  CSProj files are actually MSBuild files, but with conventions.  The conventions aren’t exactly defined anywhere.  Solution files aren’t documented anywhere at all.  In future, I expect the number of tests to grow faster than the code base.

To give you an idea of how bad it is, open up a solution file in Notepad.  Make a small modification like changing a project filename and save it to another file.  See if you can double click it.  Your chances are about 50/50.  It has to be UTF-16, and sometimes there’s a mysterious mandatory blank line at the top of the file.  

What’s Next?

Well, it’s pretty modest at the moment, but I’d like it to become a fairly general library for manipulating Visual Studio files.  .NET has fragmented, as was inevitable.  Keeping Silverlight, Mono, 4.0 and Compact Framework together is a pain at the moment.  The next problem I’d like to address is swapping between reference assemblies and project files.  Synchronizing assembly dependencies is a big deal as well.  However, like all OSS projects, the future direction is pretty much a direct function of who’s interested.

A small note: this is very early days, and the API is likely to change quite a lot as we learn more about the problem space.  If you want to use this, and really don’t want to worry about change, take a copy of the executable.  As with everything Castle Project, it’s licensed under Apache 2.0.  Finally, a big thanks to Krzysztof, who’s done a fair chunk of the testing and has put up with more dud versions than one man should.

 

Imagine you were writing the code modelling a car.  One you can drive, from the 1960s before they got too complex.  What does it look like?

class Car
{
    public void Accelerate();
    public void Brake();
}

Now, ignoring the fact that I should have started with an interface (and you can’t steer), there’s something very dangerous in this code.  It’s the assumption that a car is an object.  It’s not, it’s a phenomenally complex interlinking of components.  The driver may see it as one object, but you can be assured the manufacturer does not.

So what’s actually going on when you accelerate a car?  Well, for a start, you press down the accelerator pedal.  That’s the actual entry point to the system.  The Accelerate method is, at best, a simplification on top of that.  This opens a valve that lets petrol into the engine.  What happens then is extremely dependent upon the state of the engine.  For a start, if it’s not running, not very much is going to happen.  Indeed, your car will need some mechanism to prevent you from flooding the engine when it’s off.

We’re already creating an extremely complex object and we haven’t even started building code for the engine pistons yet.  It’s going to become a complete mess really quickly.  Unless, that is, we actually have objects that represent the physical components of the car.

The single responsibility principle is just a formalization of what we’re talking about here.  It says that a class should only do one thing and only that.  Valves should be represented by Valve objects, not by the Engine class or (shudder) implicit in the workings of the acceleration pedal.  Valve objects can then be reused for any similar valve anywhere in the car, or indeed in a power station model if it uses the same sort of valves.

Going back to how I learned to do object oriented programming, the Turbo Pascal User Guide had an example that featured a Line object.  It had properties for start point, end point and a method to draw it on the screen.

WHAT?

I can’t believe I didn’t notice how insane this was the first time I read it.  Let’s assume we’re using constructor injection.  So, to create a line object, I have to pass it a rendering context?  How about if I was trying to use it for visibility detection in a 2D maze?  I’m never going to draw the line, in fact the whole point would be that I’m not drawing the line.  And how about anti-aliasing?  Are you really going to put the logic for anti-aliasing into your line class?  It’s going to get pretty big if you do.

To put it more formally, rendering to the screen is a completely separate responsibility to that of dealing with the geometric properties.  This must have been a pretty common anti-pattern back in the day, because it’s the first thing Uncle Bob mentions in Chapter 9 of Agile Software Development.

Single Responsibilty:  It’s a Matter of Perspective

Let’s talk about the car example again.  Let’s say that we’re not trying to physically model the car this time.  Instead, we’re writing eBay Motors.  What do we care about then?  Well, mostly, model, age and colour.  Writing a car class with those properties makes complete sense this time.  There’s a well defined responsibility here: capture enough information to allow people to search for the sort of car they want.  It’s not a full model of the car, but it serves its purpose.

This is part of the point of SRP, but also its greatest problem: what exactly is a responsibility is a matter of perspective.  From the perspective of physical modelling, one approach is appropriate.  From the perspective of selling the heap of junk, quite another, simpler approach is appropriate.  Equally, a sale looks very different to different departments within a firm.  For sale people, it’s a source of commission.  For dispatch, it’s logistics.  For finance, it’s a series of payments.  These are different, linked, responsibilities and should be separated.

You’ll recognize this as an interface segregation concern, but naively applying ISP will get you into even more trouble than it’ll get you out of.  A car is a different object and a different responsibility to the designer, manufacturer and salesman.  Trying to think in terms of unified models is right up there with sacrificing chickens to the cookie monster as unproductive techniques in software development go.  It gets even worse when you’ve got multiple people working on the same project who have different perspectives on the same responsibility.  In your car model, should you be modelling wear and tear?  Air flow?  Or, to get completely ridiculous, how about radioactive decay?  Do we need a Hadron class for our car model?

Actually, what it comes down to is that applying SRP is one of the two hard things in computer science: naming.  If you can describe what a class does, you’ve got a responsibility.  If you need to use the words “and” or “also”, you haven’t.  If the description is vague, you haven’t.   Even so, different people will name the same piece of code differently.  Equally, one man’s readable code is another man’s tangle of wires.

Uncle Bob will tell you to extract till you drop.  I think, ultimately, you have to find a point at which you yourself are comfortable and productive.  As you get used to the principles and start to know them in your bones, you’ll find yourself heading closer and closer to that point.  Just don’t start modelling the weak nuclear force.

I never really felt .NET “got” SEO and ScottGu’s latest post doesn’t really fill me with confidence.  Read this:

One simple recommendation to improve the search relevancy of pages is to make sure you always output relevant “keywords” and “description” <meta> tags within the <head> section of your HTML.

Oh yeah?  Tell that to Matt Cutts.  Meta keywords haven’t had weight in any respectable search engine this millennium.  As the article explains, meta description is next to useless as well. 

What does matter? 

• The title tag.  It shows in the browser and so Google rates it as important information.  This is a welcome addition to ASP.NET 4.
• Heading tags.  They’re typically in large print and summarize the article. 
• Your URL matters, so you should try to make them readable.  URL routing has been missing from vanilla ASP.NET since day 1 and has been a pain to implement.
• Links do, even if you mark them nofollow (although they don’t count as much).
• The text of links matters as well.

So, all in all, there are some good features being covered here.  Still, it’s hard to know who this is aimed at.  If you’re writing a new solution for SEO, it’s unlikely you’d be choosing webforms anyway.  If you’ve got an existing solution, you’ve probably already solved these problems.  That probably only leaves existing solutions that are badly implemented and, frankly, these new features aren’t going to fix that.

York Notes for SEO

I don’t talk much about SEO, because it’s really hard to create posts as compelling as seomoz, but here’s pretty much everything you need to know:

• You can do a lot worse than writing content people want to read and link to.
• Observe web standards.
• Google doesn’t use Javascript on pages much.  Javascript-only links are particularly stupid.
• Age matters.  That’s why it’s better to do a permanent redirect rather than just move the page.
• Don’t try to cheat.

Here’s some things that people do all the time that don’t work:

• Writing “advertising copy” won’t help you on the web.  Google treats it as the spam that it is. 
• Slapping everything into a DIV is silly.  Use markup like h1 and blockquote for the purpose for which it was intended.

Here’s some ways of cheating that don’t work:

• White text on a white background will positively hurt.  Search engines will spot it, and will mark you down as a spammer.
• Giving radically different content to the google bot from the user is called cloaking.  This can get you in the sin bin forever.
• Link trading is basically spam.  Google will treat it as such.

Black Hatting (cheating google) is possible, but the guys who are good at it aren’t about to tell you how.

I once took advantage of the published source code of the Microsoft Enterprise Library Data Access Block to make some firm-specific modifications.  One of those changes that only really makes sense in the target environment, nothing particularly general.  The Data Access Block, for those of you who aren’t familiar with it, is basically an improved version of the ADO.NET API, with some pretty useful support for stored procedures.  It’s not NHibernate, but it’s better than coding the API in the raw.

While I was there, I decided to rip out the stuff we didn’t use.  That turned out to be nearly all of it.  This was quite shocking to me, because I thought we used a fair chunk of the functionality.  I reckon that when it came down to it, two thirds of the library was non-functional.  The vast majority of the code, which I had no interest in, was there to support ObjectBuilder. 

For those of you who aren’t familiar with it, ObjectBuilder is Enterprise Library’s configuration system.  It was created to solve the some of the same sort of problems as IoC containers, but it also addresses some interesting concerns such as providing a UI for configuration.  Enterprise Library is also the original source of my ideas on environmental deltas.

So, how did I get rid of all of this code?  Well, I junked DatabaseFactory and used constructor injection again.  It took a bit of time, but I deleted two thirds of the code without an appreciable loss of functionality.

How Much is Too Much?

Before you think this is just an exercise in ragging the Pattern & Practices group, who are a pretty easy target, I want you to ask how much code your internal and open source libraries should be devoting to configuration.  Now, I doubt you’ll find many people arguing that two thirds is the right amount.  However, I bet you’re thinking that five percent is acceptable.  I’m going to argue the correct figure here is zero.

Let’s take a look at a successful open source library: log4net.  In some ways, log4net is even worse than the Data Access Block.  At least Enterprise Library didn’t require me to use ObjectBuilder.  The code was dead and irrelevant in our applications.  log4net, on the other hand, isn’t even usable without digging into its configuration system.  Because it’s so prescriptive on this point, it then proceeds to provide several alternative approaches to how to use its configuration system.

But I don’t want to use it at all.  I’ve got Castle Windsor already, why would I want two configuration systems?  If I develop a large application with a lot of libraries, I could end up with four of five configuration files.  And pretty much all of them aren’t exactly well thought out or powerful.  Want a variable to be consistent across the files?  You’d better get coding.

And this is where it gets really ugly.  APIs defining their own configuration system doesn’t save time, it makes work for the application developer.  Configuration is right on the outside of the Onion model and should be in one place, not dotted around your system.  The choice of how to configure the system should be up to the application developer.  Look at Retlang, it has no configuration at all.  Does it make it harder to get running?  Actually no, a small program can hard code everything in the Main method, a large program can use an IoC container.

The whole philosophy of constructor injection and IoC containers is that classes shouldn’t take on externalities they don’t need.  The same applies to libraries.  Be ruthless in applying the single responsibility principle and get configuration out of your code.