# Monday, April 23, 2012

Having been a part of many large enterprise ASP.NET MVC application implementations using test driven development I learned early on that separating your controller classes into a their own project significantly reduces the noise in your web project.  It wasn’t until a recent talk I gave to user group in my region that I realized that this isn’t a widely adopted practice.  For large applications with a lot of developers and a complex architecture I highly recommend it. 

Putting your controllers in a separate assembly is very straight forward.  First create a controllers project in your solution and then you just need to update your route registrations to tell them where to look for the controllers.

  1. routes.MapRoute(name: "Default", url: "{controller}/{action}/{id}",
  2.                 namespaces: new[] {"[Namespace of the Project that contains your controllers]"},
  3.                 defaults: new {controller = "Home", action = "Index", id = UrlParameter.Optional});

In order to tell ASP.NET MVC where to look for your controllers when registering your routes you use the ‘namespaces’ parameter of the MapRoute method as illustrated above.

I know that the concept of putting controllers in a separate assembly is a bit controversial and everyone seems to have a strong opinion either for or against, so let me know what side of the fence you fall on.

posted on Monday, April 23, 2012 8:02:14 AM (Central Daylight Time, UTC-05:00)  #    Comments [12]
# Monday, January 30, 2012

The var keyword was introduced with C# 3.0 and the .NET Framework 3.5 to allow the declaration of implicitly typed variables.  The driving force behind the need for implicitly typed variables was the introduction of Anonymous Types

If you are using var outside of truly anonymous types you are doing so out of laziness.  I know this is a bold statement that a lot of developers are going to disagree with, so let me explain.

First off I totally agree that using var can speed up your lines per minute coded and I do use var in this manner.  But, I always replace var with the actual type after the fact.  You can do this with out requiring a large amount of time after the fact using a tool such as ReSharper and setting up you Clean Up Code” functionality to replace all usages of var with the actual type when possible.

Now for my supporting arguments:  *All of which only pertain to using var when the type is not truly anonymous.*

  • C# is not a Dynamic Language!  This may be bad or not ideal but it is fact.  The truth is not everyone is fluent in dynamic languages and they are not expecting to read code coded in a dynamic fashion when dealing with C#.
  • Code written in a dynamic fashion, i.e. implicitly typed , is harder to read, especially when you are not use to reading it.  I know what you are saying how is this hard to read?:
    1. var x = "This is not hard to read and understand what x is!";

    And you are correct, that example is not hard to read and figure what x is.  What about this?
    1. var x = from custs in dataContext.Customers
    2.         join orders in dataContext.Orders
    3.             on custs.CustomerId equals orders.CustomerId
    4.         join lines in dataContext.OrderLines
    5.             on orders.OrderId equals lines.OrderId
    6.         join products in dataContext.Products
    7.             on lines.ProductId equals products.ProductId
    8.             where products.Name.Contains("FooBar")
    9.         where custs.LastName.Contains("Smith")
    10.         select products

    I would much rather see and read;
    1. IQueryable<Product> x = from custs in dataContext.Customers
    2.                         join orders in dataContext.Orders
    3.                             on custs.CustomerId equals orders.CustomerId
    4.                         where custs.LastName.Contains("Foo")
    5.                         join lines in dataContext.OrderLines
    6.                             on orders.OrderId equals lines.OrderId
    7.                         where lines.Quantity > 10
    8.                         join products in dataContext.Products
    9.                             on lines.ProductId equals products.ProductId
    10.                         where products.Name.Equals("FooBar")
    11.                         where custs.LastName.Contains("Smith")
    12.                         select products;

              The truth is you know what your result is, at least you better or you have no business writing the code in the first place, so just declare it as such!

              One more thing,  var has no place in demo code, tutorials, and blog posts. The purpose of demo code, tutorials, and blog posts are to provide education and in doing so the code should be clean and concise and accessible to the masses.

              OK, let me have it.

              posted on Monday, January 30, 2012 10:00:02 AM (Central Standard Time, UTC-06:00)  #    Comments [12]