It is 1000 words, our Technical Blog FAQ was out of date. Thanks very much for the catch, we have updated the FAQ Thanks, Sean Ewington The Code Project

Thanks PIEBALDconsult both of those answers may be of some use, I must admit to leaning towards the dictionary simply because its a) simple b) can hold as many statuses as the user may want to create. Admittedly not sure how the end developer may interact with the dictionary but perhaps thats me just being dumb as not coded it yet. :)

Some cross-cutting concerns can be aggregated into "context", which is usually globally accessible. Think of HttpContext...you can access it anywhere via HttpContext.Current. Think of context from a grammatical perspective...certain words or phrases only have meaning when they are taking "in context". Same general idea with programming. A piece of code really only works when you factor in the appropriate context(s). Not everything needs to be injected, some things should be globally accessible via one or more contexts. This might help lighten your DI load so that you are only injecting direct dependencies of each class, while keeping global dependencies properly centralized.

Thanks for that Mark, works a treat. Knew it must have been something simple I was missing.

What has been worrying me is more senior experienced programmers starting to do it. Brought back horrible memories of VB6 variant

Hi Jon, I tried to email you via the link but don't know if its working. Hoping you'll get notified of this as could do with discussing the architecture. You can get me at nathans.FICTICIOUSVALUE.dropbox@NONSENSEVALUE.googlemail.RANDOMVALUE.com I'll leave you to sort out the email address ;)

Lowest of the Low wrote: I think I'll post in the C# forum about Linq Dude, there's a LINQ and .NET 3.5 forum Last modified: after originally posted -- hahaha Link! That was a good one! led mike

Ok but in such case, you won't suffer from any perf problems at all if you mark your methods/props as virtual The overhead of virtual calls is non existing when you bring html rendering and database access into the picture. Lowest of the Low wrote: In relation to your type 1 mock how would you go about using an interface when the class you are attempting to mock is unique within the app? Or am I just being dense here and you would simply replace the class interface with an explict interface and implement that in the class? Even if you do this it just 'feels' wrong having to create interfaces where a concrete class would work (from an application point of view) Well if you use them as stubs because your concrete class is not yet written (kind of the purpose of stubs) Then you would create an interface, maybe not because the app absolutely needs it in the end, but because _you_ need it to be able to continue to work before the stubbed class is actually implemented... The interfaces adds value in form of testability which make you able to develop faster and you get an app that is easier to maintain, even if they don't add much value inside the executing application itself. My Blog modified on Monday, June 9, 2008 8:01 AM

Just wanted to say thanks to everybody that posted. I came across this posting http://groups.google.co.uk/group/microsoft.public.dotnet.languages.csharp/browse_frm/thread/817b411162fa122/9ea3b34cc60bc2a2?hl=en&lnk=st&q=c%23+variables+default+values#9ea3b34cc60bc2a2[^] That goes into default values for variables and using the Activator.CreateInstance. From my set of limited tests so far String is the only Type that I've had any problems with.

When you have a List of WorkItems, you have to call the Deserialize (which inturn calls the ReadXML) multiple times to load the complete list. You will have to iterate thru the XML Reader (thru the list of WorkItem elements serialized into a single XML file) and call the Deserialize for each WorkItem element, and add the retrived WorkItem to a list. With this logic you can finally populate the List of WorkItems loaded back from XML, into which you have previously serialized the list of WorkItems. You can try this - TextReader reader = new StringReader(xmlData); System.Xml.XmlReader xmlReader = System.Xml.XmlReader.Create( reader ); List<WorkItem> workItemList = new List<WorkItem>( ); try { xmlReader.ReadStartElement( ); while ( ( xmlReader.MoveToContent( ) == XmlNodeType.Element && xmlReader.LocalName == typeof( WorkItem ).Name ) ) { workItemList.Add( ( WorkItem )new XmlSerializer( typeof( WorkItem ) ).Deserialize( xmlReader ) ); xmlReader.Read( ); } } catch (Exception ex) { } finally { xmlReader.Close(); Reader.Close(); Reader.Dispose(); }

XmlType - of course! Got so hung up on the XmlRoot that I completely forgot about that. Got it all serializing lovely now, managed it without a specific class by simply providing a XmlRoot attribute to the serializer. Thanks Tom

Lowest of the Low wrote: need to perform a cast If you look up the enum keyword (and toxxct's article I believe) it explains how enums can be promoted to int (and ARE promoted implicitly when you do arithmetic/logical ops with them). But, to assign an int to an enum, a cast is required. The second example I posted was optional casts - since the result was being assigned to an int variable anyway. The third exaple shows where the cast is required. Cheers! Mark "Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder