I was recently interview about my ASP.NET Design Patterns book for AuthorsCast.com, here what they say about the episode...
"In this episode, Scott talks about how his book builds on the existing software design literature, clears up the confusion between design patterns and design principles, explains how to quickly become proficient at applying patterns, and expounds on the benefits of creating your own ASP.NET framework. Along the way, he offers pointers on becoming a be
For my latest book Apress Pro Agile .NET Development with SCRUM & XP I am going be using NoSQL for part of the case study solution. So in order to get up to speed with some object databases I thought I might as well do some spiking starting with Db4O. I chose Db4O due to the excellent introduction to it from my fellow wiggler Dan Glyde.
To work with Db4O you will need to pop over to the Db4O project site and downloaded the assemblies to work with .NET, or al
A process that I have found useful over the last couple of years to help commit myself to some professional and personal goals is to write a letter to myself, from my future self, as if I was looking back on the coming year. The letter describes the goals both professionally and personally that I have achieved and how I have accomplished them. The process of writing goals down helps to clarify where I am heading, which enables me to focus on what I need to do to get there. It is important for
In order to keep my fat controllers thin I ensure that they are only concerned with a single responsibility, i.e. handling the coordination of my UI logic. To achieve this my controller delegates to other classes to actually perform tasks and retrieve data. However, even though I can keep my ActionResult methods thin and highly cohesive I can still end up with a very tall controller that is handling the coordination of too much UI logic. Let me show you what I mean.
I often see contro
I get asked this question a fair bit so I thought I may as well stick it up here so I can refer people to this post in future. If you are using the NHiberante native ID generator — that is, letting your database generate IDs for entities — the database will actually be hit when save is called regardless if you are in a transaction or not. This is because the entity is now part of the unit of work and thus NHibernate needs to give it a valid identity to ensure that any other objects that refer
Value objects are immutable and represent concerns in your domain that have no identity, things like Price, Currency, Money, Name, Address etc are all good candidates for value objects. Because Value objects are immutable they need to be created in a valid state, I have tended to use a Factory to ensure that Value objects were created in a valid state but lately I have been playing with code by contract style validators at construction time to ensure validity.
I was answering a post over at the ASP.NET forums on the unit of work pattern which I thought I would follow up on here.
For those of you that don't know the Unit of Work pattern, here's how Martin Fowler defines it...
"[The Unit of Work] Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems."
By the way I also cover the unit of work pattern in my ASP.NET Design Pat
I thought I would kick off my first post with how I have been using NUnit with BDD style syntax, specifically the Given, When, Then acceptance test template.
Lets take a look at an example based on the following user story and acceptance criteria scenario..
In order to get a discounted basket total As a customer I want to apply a voucher
Given I have added the following products: 1 of Hat @ 20