Voting is now open for DDD North 2014, which is excitingly going to be in Leeds. There are a lot of good talks to vote for, but my biased opionion is that the following Leeds Sharpers should all have their talks voted for.
One issue you’re likely to face while writing automated tests is that it can be tricky to check anything related to DateTimes, as they are typically accessed statically using:
The approach I’ve typically used is to create some kind of IDateProvider interface, and supply that as a dependency as needed using Dependency Injection. However, with things used throughout a system like DateTime can be, this becomes quite a chore and make the code more complex with an ever-increasing list of dependencies.
In my previous post I spoke briefly about how to setup routes and handle route arguments etc. In this post I’m going to run through the various options you have for returning and presenting your data in views. If you haven’t already I suggest you read the first part of this series.
In C# there is the readonly keyword that enforced the rule that the variable must be initialised as it's declared or in the constructor. This works as expected for simple types, but for objects and lists it's not quite like that. With a list, you can still add, remove and change items in the list. You may also expose a list as a property with a public get and a private set. You want the owner class to be able to modify the list items, but you don't want anything outside the class to modify the list items.
I might not being telling you anything new here, but a friend pointed out a good use for named parameters other than the usual optional parameters.
How many of you use ASP.NET MVC? You’re doing it wrong.
No I’m just joking. While ASP.NET is perfectly acceptable I’m here to show you an alternative, NancyFX.
In Orchard you can create your own content type by welding together several content parts. You can also add fields to a content type, but it's not obvious at first how to do this.
F# comes with a built-in Actor framework, using the MailboxProcessor class. The main reason for using actors is to simplify concurrent processing, but they also hit another sweet spot – they’re pretty good for implementing Finite State Machines (FSM).