Fredrik Normén

Avoid returning "null" and use the Null Object pattern?

Fredrik N — Thu, 22 May 2008 08:57:24 GMT

When I build applications and add methods to return a list of objects, I make it robust. So I always return an instance of the list instead or returning null. The reason is because I like the use of Count and also use foreach. I don't want to add extra code to see if the method returns null. For example:

public IList<string> GetCultures()
{
    IList<string> cultures = new List<string>();

    //...

    return cultures;
}

Then when I make a call to the GetCultures method I can see if it contains any cultures by using Count, and if I need to list Cultures I can also use foreach without getting a null exception.

IList<string> cultures = GetCultures();

if (cultures.Count > 0 )
   //..


foreach (var culture in GetCultures())
   //..

If I prefer Robustness before Correctness I return null if I only need to return a single object, for example:

public static Culture GetCulture(string cultureCode)
{
    Culture culture = null;
            
    //..

    return culture;
}

In this case I need to see if the returned object is null or not before using it.

Culture culture = GetCulture();

if (cultures !=null)

I could also throw an exception if the cultureCode could not be located, in that way I will never return null. But I try to avoid throwing exception and use try catch block when I try to get an object. The reason is performance and also skip adding several try catch block in my code.

public static Culture GetCulture(string cultureCode)
{
    Culture culture = null;
            
    //Can't locate the culture throw an exception

    return culture;
}

Culture culture = null;

try
{
    culture = GetCulture();
}
catch
{
    //...
}

I only throw an exception when it's really an exception, for example the cultureCode was in a correct format or wasn't specified etc. Everything is based on the type of application, and if Robustness is more important than Correctness. Another solution is to use the Null Object Pattern and always return an instance of an object.

Culture culture = GetCulture();

if (cultures.IsNull)

Or use the Cultures other members and not get a null exception. The Null Object Pattern is also useful if I always want to return a default value. For example if I want to get a Customer and the Customer can't be located, I could return a John Doe ;) I don't use the Null Object Pattern so often in my applications.

What solution do you use or prefer when returning a list or single object and why?

Avoid "else" as much as possible, use "?:" instead

Fredrik N — Fri, 16 May 2008 06:19:36 GMT

To have a 10 week old baby Chihuahua takes a lot of time… the housekeeping is not so easy. I need to go up twice at night to let the little baby boy do his stuff. But it’s really wonderful to have such a small dog in my home, I bought a lot of books about how to be a pack leader.. I love reading books about leadership etc so it should be interesting to read those books about packs. Here is a video on YouTube where I play with him, if anyone is interested to see a dog that has the same size as a cat puppy. http://www.youtube.com/watch?v=KOWZjHTBiKo

Well enough about dog talk. I read a book for some days ago about avoiding using “else” to use OOP. Well I try to avoid switch case and if statements as much as possible, thanks to OO it can be easy to handle that. But the interesting part in the book was just about avoiding the use of else even for a simple check.

The example in the book was like this:

if (experssion)
    return something;
else
    return somethingelse;

Instead of using “else” the author wanted us to write the following code instead:

return (expression) ? something : sometingelse;

Now we get rid of the “else”, isn’t that cool? But is it really worth it, I mean what is most readable? I think the if else in the first example is easier for people to read and understand, and also for developers that haven’t seen ?: before.

When it comes to returning true and false we could use the following code:

return (expression);

“The beauty is in the eye of the beholder” or?
What do you think, is the ?: more beauty full than if else, and is there a reason I should always use ?: instead of if else (Well it will reduce the line of code, but is that so important in this case)? What do you use and can I still use if else instead of ?: and fell like I’m writing beautiful and good code?

Use "constraints" instead of argument validation for int and double etc

Fredrik N — Sat, 10 May 2008 11:21:00 GMT

I will still continue with the argument validation track in this post also, I think it's an interesting topic.

If you haven't read my earlier posts about this topic, take a look at the following posts on my blog:

http://weblogs.asp.net/fredriknormen/archive/2008/05/07/lazy-developers.aspx

http://weblogs.asp.net/fredriknormen/archive/2008/05/08/how-to-validate-a-method-s-arguments.aspx

This time I will focus on argument of type int and double etc. Lets assume we have a method which should be used to set a price on a product:

public class Product
{
    public void SetPrice(double price)
    {
        price.RequireArgument("price")
             .GreaterOrEqualTo(0);

        //..
    }
}

Note: I will use my friend Roger Alsing cool argument validation solution in this example you can read more about it on his blog.

I use a Set method instead of a property in this example.

I use a validation here to make sure price is not lesser then 0. Here is another method that takes three argument, year, month and day as integers:

public void SetDate(int year, int month, int day)
{
    year.RequireArgument("year")
        .InRange(1900, 3000);

    month.RequireArgument("month")
        .InRange(1, 12);

    day.RequireArgument("day")
       .InRange(1, 31);

   //...
}

Note: The Day argument here is special, as we know there is not always 31 days in each month, so another kind of validation is needed, but I make this code only simple for this post.

Now lets change this code and make sure the int and double is not an argument that can take a number larger and lesser than the validation. What we do is to create a Price, Year, Month and a Day class and use them as an argument instead of double and int.

public class Price
{
       private double _price;

       public Price(double price)
       {
           price.RequireArgument("price")
                .GreaterOrEqualTo(0);

           this._price = price;
       }

       //...
   }


   public class Year
   {
       private int _year;

       public Year(int year)
       {
           year.RequireArgument("year")
               .InRange(1900, 3000);
       }

       //...
   }


   public class Month
   {
       private int _month;

       public Month(int month)
       {
           month.RequireArgument("month")
              .InRange(1, 12);
       }
   }


   public class Product
   {
       public void SetPrice(Price price)
       {
           //..
       }
}


public void SetDate(Year year, Month month, Day day)
{
    //...
}

Note: I skip the Day struct because of not adding to much code, you still get the basic ideas from the other structs.

As you see now the method takes a Price, Year, Month and a Day object, not a double or int and it will directly add a constraint. The user of the method can't pass in a invalid value. I also moved the validation to the classes instead. The Price class could be replaced with the Money pattern Fowler mention in his book if we want it to handle Money.

What do you think, is this something you use today?

How to validate a method's arguments?

Fredrik N — Thu, 08 May 2008 08:19:00 GMT

Yesterday I wrote a post about developers that skip validation of arguments. In this post I will give some example of how validation can be done. There are probably better way to do it, and that is why I need your feedback and comments.

The first example is a simple method that uses a simple validation by using “If”.

public string DoSomething(int value1, string value2)
{
    if (value1 > 10 || value1 < 0)
       throw new ArgumentException("The value must be between 0 or 10", "value1");

    if (string.IsNullOrEmpty(value2))
       throw new ArgumentException("The value can't be null or empty", "value2");

    //...
}

I started to use this solution to validate arguments, but what I notice really fast was that I repeat my self over and over again when I created more methods. I solved this by creating an ArgumentHelper class where I add my validation logic.

public static class ArgumentHelper
{
    public static void RequireRange(int value, int minValue, int maxValue, string argumentName)
    {
        if (value > maxValue || value < minValue)
           throw new ArgumentException(string.Format("The value must be between {0} and {1}", minValue, maxValue), argumentName);
    }

    public static void RequireNotNullOrEmpty(string value, string argumentName)
    {
        if (string.IsNullOrEmpty(value))
           throw new ArgumentException("The value can't be null or empty", argumentName);
    }
}

public string DoSomething(int value1, string value2)
{
    ArgumentHelper.RequireRange(value1, 0, 10, "value1");

    ArgumentHelper.RequireNotNullOrEmpty(value2, "value2");

    //...
}

With C# 3.0 we now have Extension Methods, so why not use Extension Methods to do the validation for a given type? Here is an example where I use Extension methods instead of an ArgumentHelper class:

public static class ArgumentHelperExtension
{
    public static void RequireRange(this int value, int minValue, int maxValue, string argumentName)
    {
        if (value > maxValue || value < minValue)
            throw new ArgumentException(string.Format("The value must be between {0} and {1}", minValue, maxValue), argumentName);
    }


    public static void RequireNotNullOrEmpty(this string value, string argumentName)
    {
        if (string.IsNullOrEmpty(value))
            throw new ArgumentException("The value can't be null or empty", argumentName);
    }
}

public string DoSomething(int value1, string value2)
{
    value1.RequireRange(0, 10, "value1");
    
    value2.RequireNotNullOrEmpty("value2");

    //...
}

As you can see the ArgumentHelper class have no changes, well the "this" key word is added to the first argument in the methods. I can then simply use my argument and call an Extension method that will do the validation.

I recently had a discussion with my friend Roger Alsing and he had some interesting ideas. If we take a look at the Extension Method example, we can see that we add validation extension method to a given type. Let assume we don't want to add several Extension method to the type Int, instead only one method and that method returns a given "interface" which we can extend instead. For example to Int we can have a Extension method called Require and let it return a Numeric<T>, and then we can create Extension methods for the Numeric<T> class instead:

public static string DoSomething(int value)
{
    value1.Require().InRange(0, 10, "value1");

    //...
}

Another interesting solution Roger had is the following:

static void MyMethod(string arne)
{
    RequireNotNull( () => arne);
}

static void RequireNotNull<T>(ArgDelegate<T> del)
{
    T value = del();

    FieldInfo[] fields = del.Target.GetType().GetFields(BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance);
    if (fields.Length != 1)
       throw new NotSupportedException("Invalid argument");

    string argName = fields[0].Name;

    if (value == null)
       throw new Exception(string.Format("Parameter '{0}' may not be null", argName));
}

By using this solution we don't need to pass the name of the argument as a string like in the following solutions:

ArgumentHelper.RequireRange(value1, 0, 10, "value1");

value1.RequireRange(0, 10, "value1");

Instead reflection is used to get the name of the argument. This can of course affect performance.

How do you implement your validation code, do you have some cool solution?

Why can't we just have Design By Contract support for C#... ;)

Lazy Developers?

Fredrik N — Wed, 07 May 2008 18:29:00 GMT

When I was out with my new dog (I Chihuahua, wonderful dog), I was thinking about Defensive Programming and Design by Contract. I like to do some refactoring and help other people to write cleaner code etc, not that I’m an expert in the area but I think most of developers can see stuff that blinds other developers during development. I remember a scenario that made me kind of mad, I often notice that some developers doesn’t even care to validate arguments on public API or other methods, they assume the caller pass in the right values. When I started to develop apps, I didn’t validate arguments (In know I was a noob ;)). But since I started to do validation, it reduces the number of bugs in my code, and the difference was big. But that isn’t the only reason I like to do validation. Another reason is because the caller of the method should know if they have passed a wrong value, there are of course some other reasons also, but the main reason is make sure the caller or the method pass in the correct value, and if they do, they will get what they want.

I notice that several developers today don’t care about validation, I ask them why and they all gave me the same argument “Why should I, it will only make me add more code and it’s boring to write code that checks values”. Can this be summarized that some developers are lazy?

Maybe I’m stupid because I get mad when I hear that kind of argument, but I’m special ;)

I also want Spec#

Fredrik N — Tue, 29 Apr 2008 04:45:32 GMT

I will copy Greg Young! I also want Spec#. If you also wants it, please let Microsoft know about it.

Something I like with Spec# is the support for Design by Contract.

I want verifiable software...

I WANT SPEC#!

Here is an old post about Defensive programming and Design by Contract on a routine level.

Why can't I be satisfied when I'm looking back on old applications?

Fredrik N — Mon, 28 Apr 2008 14:07:17 GMT

Most of the time I build an application I have the feeling "this is going to be a great app. Good design, nice written code and a perfect application". I think most of you had the same feeling sometimes. But when I look back on previous applications, I say "What!? NO!!! This is not good, well this could have been done much better ... omg! What have I done! .. what a bad method name....". I don't know why I often feel like that when looking back on my previous apps. When I'm looking back on my code, I always find something I could have done better. Why can't I just write the perfect app, so I can go back later and say to my self "Well Fredrik, this one is great, good work!".

(Note: I often refractoring my code to make the code better if needed..)

Is the reason because I'm mostly involved in Agile project and I think of YAGNI and KISS, or is it only that I sucks or my code blinds me... "hey where is my coding mate, I want to do eXtreme Programming!" ... hmm.. or will that help me? NO it want. The same thing here, when I look back there are always something I could have done better, and I don't think it has anything to do with Agile, even before I was using Agile I felt the same.

When will the day come when I can go back to an old app and print my code and put it on the wall and say "Hi, I wrote this!" and be satisfied. I don't think that day will come... why?.. I think it's in the nature of the developer, or!? hmmm....

How about artists, are they satisfied with the paintings they have done?... An old school teacher once told me "There is no artist that is satisfied with the painting they have done, they always say that they can do a better one!". Is is true? Hmm, I don't know I'm not that kind of artist I refer too.. well I can of course ask one:

"Is this true?".

I think we developers are artists, no WE are artist, wring code is to be an artist... isn't it!?

The configurable application, no need for recompilation and new deployment!

Fredrik N — Mon, 28 Apr 2008 08:03:00 GMT

The following I will write about is something I have used in some projects to see if it gives me any value, I haven't seen any evolutionary results yet, but maybe it's because I often move along to other projects when the previous one is completed ;)

Let assume I have a User and the User has a property called Rebate. This method can have some business logic to calculate the rebate the use has when ordering products. Here is an dummy example of the method:

class User
{
    public double Rebate
    {
        get { return superUser ? 10: 5; }
    }
}
 
User user = new User(....);
double rebate = user.Rebate;

The business rule for calculating the Rebate is something that can be changed in the future based in new business needs. Can we do the changes without a new recompilation and deployment of the application?

By using the Interfaces and also the Factory Pattern we could solve this. Here is an example where an Interface is added to the User and a Factory is used to create the User:

public interface IUser
{
    double Rebate { get; }
}

class User : IUser
{
    public double Rebate
    {
        get { return superUser ? 10: 5; }
    }
}
 
IUser user = UserFactory.Create(...);
double rebate = user.Rebate;

The UserFactory will now create an User an return an IUser. Because the factory creates the user I don't use "new User". I can now use late binding and load the assembly which has the implementation of the User and return it. I can for example use a configuration file where I specify the type of the user I want use.

The UserFactory can now load the type specified in the configuration file and create an instance of it. If I need an new version of the User because
some changes need to made based on business needs, I can create a new assembly and a new IUser. I can then modify my configuration file to make sure the UserFactory loads my new implementation. By using this solution I don't need to compile my application when changes to classes is needed. Instead I create a new version of the class, put it into a new version of the assembly and deploy it. Then I only change the configuration file so the Factory gets my new implementation instead of the old version.

class User : IUser
{
    public double Rebate
    {
        get { return IsMegaUser() ? 11: 6; }
    }
}

Another solution to solve this could be to use Dependency Injection, where I inject a object with the implementation of the business logic. I can then for example use Spring.Net to inject the business object into my User. By using Spring.Net I can in a configuration file specify which business object that should be injected to the User class when it's instantiated. This will make it possible to only implement a new version of the business object rather then a new version of the User. I will not use this solution because it can be kind of ugly. But by using Spring.Net I can hide the injection of the dependency and never see it in my code. Let's think like an Object, would you like someone to easy change your behavior and you can't do any thing about it?

I sometimes uses Interfaces and in some cases Factories, but not so often (It depends on the project and if the Customer already have specified a design to use). I use interfaces and factories when I want my application to be plugable, for example make it easy to inject Repositories into my Services etc, and also to make it possible to use Mock object during test etc.

About using this solution for most of the classes in a application, wouldn't it in an Agile project sort of violate YAGNI!?

It can sort of help the people that need to maintain the application after it's deployed, as long as the interface of the classes can be intact. What do you think about it? Is this something you use today in your application and have it result into something good?

Can the use of Extension methods break the Law of Demeter?

Fredrik N — Fri, 25 Apr 2008 19:05:26 GMT

To make an easy description of Law of Demeter we can summarize it to the following sentence:

“In particular, an object should avoid invoking methods of a member object returned by another method.”

What does this has to do with Extension methods? It depends on how it’s used. For example we have several Extension Methods for the IEnumerable interface, like Where and OrderBy. By using those methods we can easy select data out from lists, for example (I’m so worthless when it comes to give methods good name, and the following method is so stupid, but it’s only an example.):

public IList<int> GetNumbersGreaterThanTwo(IList<int> numbers)
{
         return numbers
                       .Where(n=> n > 2)
                       .OrderBy(n => n);
}

If this code should not break the law of Demeter, it will look like this:

public IList<int> GetNumbersGreaterThanTwo(IList<int> numbers)
{
    var result = numbers.Where(n=> n>2);
    return result.OrderBy(n => n);
}

But that is not true, regarding to the book The Pragmatic Programmer, we don’t “own” result and it wasn’t passed to us, so we can’t use OrderBy. So we break the law. How about using LINQ instead?

public IList<int> GetNumbersGreaterThanTwo(IList<int> numbers)
{
     return (from n in numbers
                    where n > 2
                   select n).ToList();
}

Will it break it?

If we have the following Extension method:

public static class StringExtension
{
        public static int ToInt(this string value)
        {
            if (string.IsNullOrEmpty(value))
                return 0;
            return Int32.Parse(value);
        }
}

And use it in like this:

int number = 45.ToString().ToInt();

Yes, I know, why make an Int a string and then back to an Int, well I’m so bad when it comes to write good examples too ;)

Will the code break the Law of Demeter?

If I have understood how Extension method works, it will not. Why? Well it’s because an Extension method is only a compiler trick, the compiler will change the above code into something like this (Please correct me if I’m totally wrong):

string temp = 45.ToString();
int number = StringExtension.ToInt(temp); 

public static class StringExtension
{
     public static int ToInt(string value)
     {
          if (string.IsNullOrEmpty(value))
              return 0;
          return Int32.Parse(value);
     }
}

Should we even care about this Law at all? Well is some cases, and in some not. I don’t think we should slavery follow it. I try to avoid larger response sets, but I will still write my code as the first example in my post where I use Where and OrderBy, I will not split it down and create extra wrapper methods to avoid breaking the Law. The reason I will break the law in that case is because I think it’s more readable and easy to understand. By using wrapper methods etc for that example, only make the code smell

Here are some examples I try to avoid, only to give you at least some examples:

ds.Tables[0].Rows[10].Cols[5].ToString(); 

customerRepository.GetCustomerById(10).FirstName 

myPlaceHolder.FindControl("TextBox").Text = "text"; 

myPlaceHolder.FindControl("myPlacehodler2").FindControl("Button").Text = "My Button";

Regarding to the book The Pragmatic Programmer, there was studies which shown that classes in C++ with larger response sets are more prone to error than classes with smaller response sets.

“System with many unnecessary dependencies are very hard (and expensive) to maintain, and tend to be highly unstable. In order to keep the dependencies to a minimum, we’ll use the Law of Demeter to design our methods and functions.” – The Pragmatic Programmer page. 140

What purpose does the Repository Pattern have?

Fredrik N — Thu, 24 Apr 2008 15:20:53 GMT

I have watch Rob Conery’s great screencast about MVC Storefront. If you haven’t seen them, you should take a look. Really interesting, he build and app by using Agile, "TDD" etc. I have some comments about his implementation I want to share, and if you don't agree with me, it's fine, because I'm not an expert, this post is based on my own experience and knowledge ;)

Feel absolutely free to criticize me, but please give suggestions about what things can be done better, and also a reason why. There is no use if you add comments like "I don't agree with you!" if you don't say why.

Something that I don’t like with his implementation so far is his use of the Repository Pattern. I don't know what pattern Rob refer to, I assume it's Fowler's Repository Pattern. This post is based on my experience and interpretation of the Repository pattern, only so you know.

Rob creates a Repository which has a simple interface, he have for example a method GetCategories which returns an IQueryable<Category> object.

public interface ICategoryRepository
{
        IQueryable<Category> GetCategories();
}

He also use the Service layer to implement common used queries such as GetCategories.

public class CategoryService
{
    //...

    public IList<Category> GetCategories()
    {
        return _repository.GetCategories().ToList();
    }
}

Another method that Rob put in to the Service Layer is GetProductsByCategory(int categoryId).

This is the part I don’t like; I will try to explain why and based on my knowledge and experience of the Repository pattern.

The Repository has a responsibility to return entities. What Rod does is returning an IQueryable object, a query nothing else. So his Repository basically don’t return any entities, it’s when he first make a call to the ToList() he execute the query and then get the entities, but it’s the object he returns from the Repository that gives him the entities, not the Repository itself. For me the Repository he use is sort of meaningless; it only works as a query provider not as a Repository regarding to the definition of the Repository Pattern.

“The Repository will delegate to the appropriate infrastructure services to get the job done. Encapsulating in the mechanisms of storage, retrieval and query is the most basic feature of a Repository implementation”

“With a Repository, client code constructs the criteria and then passes them to the Repository, asking it to select those of its objects that match. From the client code’s perspective, there’s no notion of query “execution”; rather there’s the selection of appropriate object through the “satisfaction” of the query’s specification.”

“Most common queries should also be hard coded to the Repositories as methods.”

Source: PoEAA [Fowler] and DDD [Evans]

The interface of a Repository I should have used if I should slavery follow the definition of the Repository pattern is:

public interface IProductRepository
{
    //...

    public IList<Product> GetProductsByCategory(int categoryID);

    public IList<Products> GetProducts();
}

What infrastructure service the Repository should use is something I will decide later in my project (This is also something Rob mention in his screencasts), first I will make sure my Domain Model is correct, then I decide based on my model what infrastructure service I should use to persist my model. The way to persist my model is something I probably never going to change, and to follow YAGNI which is a important part when working Agile, I shouldn't care or write code which make is possible to easy replace the infrastructure service a Repository use because I think it may change or I may need it later. But if I decide to use LINQ to SQL, the implementation of my Repository will probably look like this:

public class ProductRepository : IProductRepository
{
    public IList<Product> GetProductsByCategory(int categoryID)
    {
        using (MyDataContext dataContext = new MyDataContext())
        {
            return (from p in _dataContext.Products
                    where p.CategoryId == categoryID
                    select p).ToList();
        }
    }
}

Something to observe here is that I dispose the DataContext after I execute my Query. By doing that I will lose the track changing of my entities, my Unit of Work and also my Identity map which is handle by the Context. But when I write this code using Agile, I don't need it at the moment.

My Mock object for the ProductRepository would probably look like this:

public class MockProductRepository : IProductRepository
{
       public IList<Product> GetProducts()
       {
           var products = new List<Product>();

           for (int i = 0; i < 10; i++)
               products.Add(new Product(.....));

           return products;
       }


       public IList<Product> GetProductsByCategory(int categoryID)
       {
           var products = this.GetProducts();

           return (from p in products
                   where p.CategoryID == categoryID
                   select p).Single();
       }

       //...
}

If we return an IQueryable<> instead of a IList from our Repository and decide to use LINQ To SQL, we will need to have something in mind. Correct me if I'm wrong, but the GetTable method used by LINQ to SQL will return a Table<> object, which implements the IQueryable<> interface. The Table<> object will hold a reference to the DataContext. So a call to the ToList() method of the IQueryable<> require the context. So the following code will not work:

public class ProductRepository : IProductRepository
{
    public IQueryable<Product> GetProductsByCategory(int categoryID)
    {
        using (MyDataContext dataContext = new MyDataContext())
        {
            return dataContext.Products;
        }
    }
}

The implementation of the Repository can for example look like this to make it work:

public class ProductRepository : IProductRepository
{
     private MyDataContext dataContext = new MyDataContext();
     
     public IQueryable<Product> GetProductsByCategory(int categoryID)
     {
         return dataContext.Products;
     }
}

What does this code really do? Well it only expose Table<> objects at the moment and serve more like a query provider than as a Repository.

If we still keep this implementation we need to make sure the DataContext get disposed, so we don't add to much unnecessary entities to the Identity map etc, right!? This is something the Service layer need to do if we use the solution Rob uses in his project. If we don't want to reuse the same context for all method in our Repository we can use the following implementation:

public class ProductRepository : IProductRepository
{
    public IQueryable<Product> GetProductsByCategory(int categoryID)
    {
        MyDataContext dataContext = new MyDataContext();

        return dataContext.Products;
    }
}

The problem here is that each call to the Repository's methods, will create an instance of the DataContext which will be added to the memory, each will have it's on Identity Map etc, those features can probably be turned of so it will not be unnecessary copies of entities in the memory. But still I assume we need to have more things in concern when returning a IQueryable<>, maybe not at an early stage but later. Most of those can be avoided by not returning the IQuerable<>.

One last thing that I'm not a fan about is the following code:

return _repository.GetProducts.WithId(10).ToList();

It will break the Law of Demeter. Instead if we do a call like this:

return _repository.GetProductsWithId(10);

We will not break the law, and this is the kind of method a Repository should have, if the query of a products is a common query we need to use.

No one says that the Repository pattern Fowler and Evans talk about is a Silver bullet, and Rob has a good point when he told me:

“One thing I’ll suggest is that with a new feature set (.NET 3.5) comes some new ways of doing things.”

Even within the computer world, there are evolutions and we shouldn’t be afraid of changes and test new way to solve things.

It will be interesting to see how the final version of Rob's application will look like, maybe I will change my mind or his implementation will change ;)

ASP.Net MVC Framework - How do I design my apps with the MVC pattern and +P

Fredrik N — Tue, 22 Apr 2008 20:36:00 GMT

When I'm playing around with the ASP.NET MVC Framework I have created several prototype applications with different solutions to solve some "problems." In this post I will write down how I combine a Presentation Model (When I talk about Presentation Model in this post, I refer to a model which purpose is only to define a model for presentation purpose) with the MVC, it's what the P in MVC+P stands for.

When I build apps today I use Domain Driven Design and I use the MVC pattern in some of my web based applications. As many of you know the M in MVC stands for the Model and contains our entities, business logic can data access components. Often when I build my apps with the ASP.Net MVC Framework (still only use in as a prototype because the framework is under development) I create my own custom Controller Factory to support Dependency Injection (DI). For example I use constructor injection or setter injection to inject my Repositories or manual injection of Mock objects during test. I use Spring.Net as my DI framework because it’s the framework I like the most.

Here is a simple example how my Controllers can look like and are prepared for constructor injection:


public class HomeController : Controller
{
    ICompanyRepository _companyRepository;

    public HomeController() : this(new CompanyRepository()) { }

    public HomeController(ICompanyRepository companyRepository)
    {
        this._companyRepository = companyRepository;
    }

    public ActionResult Index()
    {
        CompanyInfo companyInfo = this._companyRepository.GetCompanyInfo();
        return RenderView("Index", companyInfo);
    }
}

As you can see I create an instance of a CompanyRepository in the default constructor, the reason to this is because if I create a normal instance of the HomeController, I want it to use a default Repository. I also have a constructor which takes a ICompanyRepository as an argument, this is because to enable constructor injection. I can use the constructor to pass in my Mock object of the CompanyRepository, or I can use Spring.Net to inject a ICompanyRepository, which I use in my own custom Controller Factory. Here is how my test could look like where I have a Mock object for the CompanyRepository:

    MockCompanyRepository mockCompanyRepository = new MockCompanyRepository();

    mockCompanyRepository.Create(new CompanyInfo("........"));

    CompanyController companyController = new CompanyController(mockCompanyRepository);

    var result = CompanyController.Index() as RenderViewResult;

    //Assert...

Note: If you have read my Step by Step Guide, I use the LINQ to SQL's DataContext object directly in my Controllers, it's because they can sometimes serve as a "Repository" because the power of the LINQ.

When I use MasterPage which should always render a part of my Model, like content for a Menu etc, or when I need to render more than one entities of my Model, I need to make sure my Controllers will fill the ViewData property with more information than just one single entity from my Model. In this case I may have several Repositories which I need to call from my Controllers. If I use constructor injection, I need to add an argument to a Controller's constructor for each Repository. This can make the constructor cumbersome. To solve the issue and reduce the number of argument, I instead use setter injection, so I inject the Repositories needed through a set method (using properties). By doing this I can easy manually inject my Mock objects in my test:

    MockCompanyRepository mockCompanyRepository = new MockCompanyRepository();
    MockCustomerRepository mockCustomerRepository = new MockCustomerRepository();

    //...

    CompanyController companyController = new CompanyController();

    companyController.CompanyRepository = mockCompanyRepository;
    companyController.CustomerRepository = mockCustomerRepository;

    var result = CompanyController.Index() as RenderViewResult;

    //Assert...

I can still reuse my own custom Controller Factory without changes to support setter injection, because I simple only let Spring.Net know that I want to inject my Repositories by using setter injection. When I use setter injection, I don't create an instance of the default Repository or Repositories in the default constructor of the Controller.

The following is an example of a Controller which uses to Repositories and pass two entities to the "View":

public class HomeController : Controller
{
    ICompanyRepository _companyRepository;
    ICustomerRepository _customerRepository;

    public HomeController() { }


    public ActionResult Index()
    {
        ViewData["CompanyInfo"] = this.CompanyRepository.GetCompanyInfo();
        ViewData["Customer"] = this.CustomerRepository.GetCustomer();
        
        return RenderView();
    }

    
    public ICustomerRepository CustomerRepository
    {
        get
        {
            if (this._customerRepository == null)
                this._customerRepository = new CustomerRepository();

            return this._customerRepository;
        }
        set
        {
            this._customerRepository = value;
        }
    }


    public ICompanyRepository CompanyRepository
    {
        get
        {
            if (this._companyRepository == null)
                this._companyRepository = new CompanyRepository();

            return this._companyRepository;
        }
        set
        {
            this._companyRepository = value;
        }
    }

}

The Index method will now return two entities. Assume the CompanyInfo is for the MasterPage and the Customer for the Content Page. The ViewData property in this case will sort of be a Presentation Model ("The essence of a Presentation Model is of a fully self-contained class that represents all the data and behavior of the UI window") but don't contain any behavior.

Something that can make the above Controller or other Controllers ugly and start to smell, is when most action method must set the ViewData for the Model which the MasterPage will render. There is a tiny little problem regarding to how I will work and think when it comes to Test Driven Developement, when I use a MasterPage or User Controls on a View which will render different models. The problem is, when I create a test for a Controller before the Controller is implemented, I must know about what Models the UI will render, all entity objects even for the MasterPage and User Controls. I can't only assume that the CustomerController's List action method will return a list of Customers, I also need to have in mind the model the MasterPage and User Controls will use and when writing the test. Well basically I can ignore it, but it can affect how my ViewData will look like, and what key I need to use to get access to my list of Customers etc. This is something that I don't want to care about for every action method I want to create a test for. I also like the way I can type the ViewData property for the View. To solve the issue I decided to create a base class called PresentationModel. This class have one typed property for the model the MasterPage should render, MasterPageModel and one for the Repository which will get the Model for the MastePage, here is an example:

public class PresentationModel
{
    private CompanyInfo _companyInfo;

    public CompanyInfo MasterPageModel
    {
        get
        {
            if (this.CompanyRepository == null)
                throw new ApplicationException("A ICompanyRepository must be set");

            if (this._companInfo == null)
                this._companyInfo = this.CompanyRepository.GetCompanyInfo();

            return this._companyInfo;
        }
        set
        {
            this._companyInfo = value;
        }
    }

    public ICompanyRepository CompanyRepository { get; set; }
}

If the Model or the MasterPage is changed and that affect what the MastePage should render, I only need to change what model the PresentationModel class returns through the MastePageModel property, I don't need to go through all action methods and update them. That is one benefit with this design solution.

Note: I use a property for the CompanyRepository to make it easy to add a Mock object in my tests.

The PresentationModel is the type I specify for the MastePage to make it typed.

public partial class Site : System.Web.Mvc.ViewMasterPage<PresentationModel>
{
}

I then create a sub class of the PresentationModel called GenericPresentationModel. The GenericPresentaionModel class is a generic class which inherits from the PresentationModel and have a generic property called Model.

public class GenericPresentationModel<T> : PresentationModel
{
    public GenericPresentationModel() {}

    public GenericPresentationModel(T model)
    {
        this.Model = model;
    }

    public T Model { get; set; }
}

The Controllers can now use the GenericPresentationModel and pass it to the View, the following Controller has an Action method which will render a Customer:


public ActionResult Index()
{
    Customer customer = this.CustomerRepository.GetCustomer();

    var presentationModel = new GenericPresentationModel<Customer>(customer);

    return RenderView("Index", presentationModel);
}

Because I pass the GenericPresentationModel to my View, I can also type the View:

public partial class CustomerView : ViewPage<GenericresentationModel<Customer>>
{
}

Then my ViewData property of my View will be of Type GenericPresentationModel<Customer>. So I can easy get access to my Customer by using ViewData.Model.

The following example shows how the test of an Action which will render a Customer could look like:


        MockCustomerRepository mockCustomerRepository = new MockCustomerRepository();

        //...

        HomeController controller = new HomeController();
        controller.CustomerRepository = mockCustomerRepository();

        var result = controller.Index() as RenderViewResult;

        var presentationModel = result.ViewData as GenericPresentationModel<Customer>;

        //Assert.....

Because I don't use the MastePageModel property in my test of the Index method, I don't need to inject the Mock Repository for the PresentationModel base class. When I created the PresentationModel I have already created a test to make sure the PresentationModel returns the correct data, so I don't need to care about testing that again in my other tests.

I still use this approach in a prototype solution to see how well it will work. When I work with Domain Driven Design I often need to render different information from different entities from my domain model. In my case I don't always want to pass several entities to my Views, so instead I create new object that will combine information from different entities, with another word, I create a Presentation Model. Most larger apps which I have created with the ASP.Net MVC Framework, often result in the use of a Presentation Model, and that is the P in the MVC+P. I know that several people don't like this because it requires us to create a lot of extra classes, but the benefits is that the Views will use the Presentation Model and don't even need to know about the domain model. If we don't pass a single entity from our domain model to the View, instead we use a Presentation Model and map the domain model to the Presentation Model, we can change the domain model, and it doesn't need to change the Views, only the mapping between the Presentation Model and the domain model. To be honest I don't create a complete Presentation Model, I still pass entities from the domain model to the View, mostly to keep it simple and not spend extra time to write new classes for each View.

I'm interested about what you think, how you solve similar problems, do you use similar solutions that I do and have notice problems that I haven't notice yet, please let me know.

Do you want to become a great developer?

Fredrik N — Fri, 18 Apr 2008 15:12:25 GMT

I found this old post on my old blog and still think it may have some good book tips which I will share with you on my new blog, where I also have new visitors.

In this post I will give my suggestions of books that in my opinion could make you become a great developer. Remember that books will only give you theoretical knowledge and not the practical knowledge, so you also need to use your knowledge and do some practical programming to success. You will also learn from your mistakes and the best way to succeed is to follow those who have succeeded.

Note: I assume you already have some great skills in some programming language, such as C#, VB.Net, Java and C/C++ etc. The books I will list in this post will be easier to understand if you have basic knowledge in C#, C/C++ or Java. Most examples in the book are written in Java, C# or C/C++.

Before you start your path to become a great developer, I should suggest you to read the following book:

The Balanced Life: Achieving Success in Work & Love - Alan McGinnis

To become a great developer you will need time, and you should be careful so you don’t scarify the one you love.

Read the books in the order they are listed:

Learn how to become a Pragmatic programmer:

1) The Pragmatic Programmer - Andrew Hunt, David Thomas

Learn how to write well structured code

2) Code Complete, Second Edition - Steve McConnell

Learn about how to write secure code

3) Writing Secure Code 2:Edition - Howard and LeBlanc

Learn about Object Oriented thought process

4) The Object-Oriented thought Process – Matt Weisfeld