Whenever I develop an MVC application there is always some degree of data access required. As a best practice, I usually define a interface that my repository objects will adhere to. Creating an interface is generally a requirement for Dependency Injection (DI). DI is a very important pattern if you plan on doing any unit testing later on. For the purpose of this demo, I am going to keep things simple and only create a fake repository.  Here is the code: public interface IRepository { Person GetPerson( int id ); } public class FakeRepository : IRepository { public Person GetPerson( int id ) { return new Person { Id = id, FirstName = "Mike", LastName = "Ceranski" }; } } Obviously, in a real-world application you would probably utilize the Entity Framework or LINQ to SQL in order to implement the IRepository interface. However, for the purposes of this demo the FakeRepository illustrates the point. Moving on, the n... [More]

One of the hardest things to unit test in MVC is security. Security is tough to test because there is a lot of setup involved in mocking the HttpContext, the Principal and the Identity. For example, in WeBlog I am using the following code in the Edit Post action. Post post = Repository.FirstOrDefault<Post>(x => x.ID == id); if (post == null) return View("NotFound"); if (!HttpContext.User.CanEditPost(post)) return View("PermissionDenied"); In order to make sure this code works properly I need to test it with an authorized and unauthorized user. Unfortunately, the HttpContext.User will not automatically be created for your tests so you have to mock one for each test that your perform. So lets start this journey by reviewing the code required to mock the HttpContext using the popular opensource library Moq. This code is a combination of code I discovered on Stackoverflow and Scott Hanselman’s MvcMockHelpers: MockContext public static Mock<Htt... [More]

As a .NET developer you will probably create hundred of configuration files over the course of your career. Most of the time when we use a configuration file it is for simple things like a database connection string. However, sometimes configuration data needs to be relational and can require a more complex structure than traditional name value pairs. For example, lets say that I am developing a data import tool which uses the configuration file to store data mapping information. Here is an example of what my configuration file might look  like: <import> <jobs> <job name="Foo"> <fieldMappings> <mapping source="column1" destination="TimeStamp"/> <mapping source="column2" destination="Name"/> </fieldMappings> </job> <job name="Bar"> <fieldMappings> <... [More]

If you are a ASP.NET web developer than chances are that you have heard of or dealt with problems related to “Magic Strings”. Magic strings are taboo because they introduce a degree of fragility in your code due to the fact that they are not strongly typed. The classic example, is referencing a View Name or Route in your controller action using a string value: public class HomeController : Controller { public ActionResult Index() { return RedirectToAction("Foo"); } public ActionResult Foo() { return View(); } } As you would expect, when the Index action is invoked the user gets redirected to “Foo”. Unfortunately, if I rename the “Foo” method to “Bar” my code will still compile but it will ultimately fail at runtime. This is all due to the fact that are RedirectToAction method is using the magic string “Foo” which is not strongly typed and therefore not caught by the compiler. As a workaround to this ... [More]

What is ELMAH? In case you have been living under a rock I will start this block post by giving you a basic introduction to ELMAH. If you already are familiar with ELMAH then just skip to the next section. The following description was taken verbatim from the ELMAH website… ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment. Once ELMAH has been dropped into a running web application and configured appropriately, you get the following facilities without changing a single line of your code: Logging of nearly all unhandled exceptions. A web page to remotely view the entire log of recoded exceptions. A web page to remotely view the full details of any one logged exception. In many cases, you can review the original yellow screen of deat... [More]