Posts

Showing posts from December, 2008

I couldn't possibly say this any better...

Comment by LKM on http://www.codinghorror.com/blog/archives/001201.html : About convenience: Pirated media is not free to the pirate. He pays with his time. Now you can't compete with the price of time for people who don't work. To most teenagers, time is way less valuable than money. No matter how convenient you make buying your stuff, these people won't give you their money. However, that is not the case for people who have jobs. To people like us, even finding a working torrent file may not be worth the hassle if we can instead open the Amazon MP3 store, type the name of the song we want and click "buy". In many cases, the price doesn't even enter the equation. To me, whether I have ten bucks more or less on my credit card statement at the end of the month simply doesn't matter at all. What matters is whether I spend ten minutes looking for a song, or ten seconds. Ironically, DRM makes it *less* convenient to buy, thus giving potential customers more in

Repository pattern

[Edited on June 6, 2009.] This is my implementation of the Repository pattern in C#; I am using the ServiceLocator defined in my previous post . This is the main interface: public   interface  IRepository<TEntity, TId>     where TEntity: IEntity<TId>   {      /// <summary>       /// Returns all entities in the repository       /// </summary>       /// <returns>List of entities</returns>      IEnumerable<TEntity> GetAll();         /// <summary>       /// Returns all entities matching a criteria       /// </summary>       /// <param name="criteria">Criteria to be matched</param>       /// <returns>All entities matching the criteria; should not be null, but it can be an empty list</returns>      IEnumerable<TEntity> FindAll(Expression<Func<TEntity,  bool >> criteria);         /// <summary>       /// Returns the first entity matching a criteria       /// </summary>       //

ServiceLocator redivivus

This is the (so far) final form of the ServiceLocator class: using  System;   using  System.Collections.Generic;   using  System.Linq;   using  System.Reflection;      namespace  Helper   {      public   static   class  ServiceLocator     {        private   static   readonly  Dictionary<Type, Func< object >> container =  new  Dictionary<Type, Func< object >>();        private   static   readonly   object  containerLock =  new   object ();           public   static  Func<Type,  object > OnTypeNotFound =         type => {  throw   new  NotSupportedException( "Cannot resolve type "  + type); };           /// <summary>         /// Discovers all the classes decorated with the Register attribute and registers them as implementations of the ImplementedType argument         /// </summary>         public   static   void  Discover()       {         var types = Assembly.GetCallingAssembly().GetTypes().ToList();         types.ForEach(type =>

5-minute dependency injection container in C#

I found Misko Hevery's talks on the usefulness of Dependency Injection to be quite persuasive, so I have started using constructor DI in my projects. Unfortunately, some of those involve ASP.NET WebForms applications, and even in the one I just started using ASP.NET MVC there are classes I do not create myself (like the controllers). This means that when I write something like public   class  ProductController   {      private  ProductRepository repository;         public  ProductController()     {       repository =  new  ProductRepository();     }   }   I am hard-coding a dependency on the concrete ProductRepository class inside ProductController. There are (at least) two solutions to this. One of them would be to create a property in the ProductController class: public  IProductRepository Repository {  get ;  set ; }   and change the constructor to public  ProductController()   {     Repository =  new  ProductRepository();   }   This is the usual property dependency injection,

Important pattern in C#

While programming, one sometimes needs static methods - methods that cannot meaningfully be associated with an object (a class instance). One example that comes to mind is Math.Abs, but Factory.CreateCustomer might be another. On the other hand, static methods make the methods that use them hard to test - what do you do if you try to test a method that calls Factory.CreateCustomer()? You don't want it to do that, you might want to return a fake customer, or null, or a NullCustomer - any of a number of choices. One solution - the most recommended one, in fact, as far as I can tell - is to extract the method in an interface (IFactory.CreateCustomer) and pass an instance of that interface to either the constructor of the class under test, or directly to the tested method. Which is nice, except sometimes you can't alter the constructor of a class (like Pages in ASP.NET and Entities when working with Linq to Sql), and passing the interface to each method looks somewhat ugly. A few d