Several people have asked me about using data annotations for validation outside of a UI framework, like ASP.NET MVC or Silverlight. The System.ComponentModel.DataAnnotations assembly contains everything you need to execute validation logic in the annotations. Specifically, there is a static Validator class to execute the validation rules. For example, let's say you have the following class in a console mode application: public class Recipe { [Required] public string Name { get; set; } } You could validate the recipe with the following code: var recipe = new Recipe(); var context = new ValidationContext(recipe, serviceProvider: null, items: null); var...

This post is a play on Phil's "A Better Razor Foreach Loop".  If you aren't familiar with templated delegates in Razor, you can follow the links in Phil's post. Something I don't like to see in a view is the if null or empty check. @if (!String.IsNullOrEmpty(User.Identity.Name)) { <span>Logged in as: @User.Identity.Name</span> } There are a number of ways to remove the check, but the knowledge in Phil's post give you one more option -  the HTML helper option. public static class RazorExtensions { public static HelperResult Maybe(this string...

 workplace [n] - a place where work is done Over the years I've worked with developers in cubicle farms and private offices, in open spaces and cloistered bureaus. And once there was a basement room across the hall from a mortuary, but I try to forget about that project. The workplace affects the contentment of its captives, but for some developers the workplace isn't entirely about coffee machines and cafeterias. The workplace is where they spend their hours thinking, creating, and producing. It's not the cubicle, but the computer,the tools, and the code. Bad code gives these...

If you want to simulate an exception from an IQueryable data source, be careful about when the exception is thrown. As an example, let's use the following interface. public interface IContext { IQueryable<Person> People { get; set; } } To simulate an IllegalOperationException from the data source, you might setup a mock with the following code. var mockContext = new Mock<IContext>(); mockContext.SetupGet(c => c.People) .Throws<InvalidOperationException>(); But, the mock will throw the exception as soon as something touches the People property. With a real data source, the exception won't happen until...

I like Kzu's take on building unit-testable domain models with EF code first. I've been playing around with some of the same ideas myself, which center around simple context abstractions. public interface IDomainContext { IQueryable<Restaurant> Restaurants { get; } IQueryable<Recipe> Recipes { get; } int SaveChanges(); void Save<T>(T entity); void Delete<T>(T entity); } It's easy to mock an IDbContext,  but I wanted  a fake. My first brute force implementation had loads of messy problems in the Save and Delete methods. Here is an excerpt. class FakeDbContext...