The Id attribute in Backbone is very important. Backbone uses it to determine if an object is new, or already existed. Collections use it to determine if it already contains any given object.

So I ran into a problem in a situation where my model required a lot of “supporting data” before it was saved. To add this data, I decided to create the models on the server and add it to a collection (since there were a whole list of them).

No matter how many models I added to the list, only the first one was rendered. Why? Because my model on the server was using a non-nullable Integer as its Id property like this:

public class Account
{
	public int Id { get; set; }
}

So of course, all the models returned from the server had an Id of zero! And of course, Backbone thought that they were all the same instance since they shared the same Id.

Small change, huge impact

Talk about a single character making a huge impact!

By adding the silly question mark to the Id property, everything was working. That’s because a Nullable integer is not added to the JSON returned by the server, and Backbone then knows that this model does not exist!

The post Backbone and ASP.NET MVC: Use Nullable types as Id appeared first on Martin Normark's blog.

Here are three reasons why you should use truly dedicated view-models for any view in ASP.NET MVC.

1. Abstract code beyond your control

If you work on a web team, that is part of a larger team you cannot expect to always have the entire back-end ready at the time you want to start coding a feature for the front-end. But why wait? Even if you don’t have the service layer, the domain models or the database ready, you can just easily create dummy instances of your view-model in a controller and return that to the view.

You can get started coding the UI, the JavaScript, maybe hook up your Backbone models or anything similar.

You are also in complete control of the design of the view-models, and it often turns out that they end up a hell of a lot different from the domain models.

2. Keep view oriented data annotations out of the domain model

You want to use both validation attributes, UIHints, template information and a lot of other view oriented stuff that should stay inside the MVC project.

The problem is that if you throw all these things on the domain model, you suddenly have a dependency on ASP.NET MVC and Razor which means that you must add reference to these dependencies from your lower tiers. Not good!

3. Defend your JavaScript from outside changes

JavaScript is playing a bigger and bigger part in modern web development. So the more JavaScript your write that manipulates your view-models, the more exposed you become to outside changes.

Having a dedicated view-model makes you in control, and not the DBA or any other dude who doesn’t care about the front-end.

How to avoid repeating yourself

It’s probably the worst argument against view-models, that you end up repeating the domain-models. If you think that, you’ve missed something.

The point of a view-model is to make it as closely tied to the view as possible. This will make the view a lot more simple, which is a good thing.

For mapping a domain-model to a view-model and vice-versa, I use AutoMapper which is extremely simple, yet powerful.

The post 3 Reasons Why Dedicated ViewModels in ASP.NET MVC is a *MUST* appeared first on Martin Normark's blog.

The thing is, naming conventions across languages does not always agree. In .Net properties are named in PascalCase. In JavaScript camelCase is the standard, so naturally this leads to a conflict when your model in Backbone names the ID attribute id, and the corresponding domain model on the server side is named Id.

I was using an ASP.NET MVC controller to return a collection of Accounts, but when it hit the client, got changed and later saved, the ID was lost and the model was created as a new instance in the database.

The problem was that when Backbone fetched the collection, and automatically turned the objects in the array into instances of Account — Backbone was expecting to find every model’s ID in the id property, which did not exist. And on the server, it uses Id to know if this model is new or already exists.

Change the idAttribute

It turns out that Backbone is designed for this.

Whenever you define your models, you need to set the value of the idAttribute property like this:

var Account = Backbone.Model.extend({
	idAttribute: "Id"
});

But that’s a bit annoying since you’ll have to remember this on each and every model. And you need to define your own model every time, you can’t just create a new instance of the stock Backbone.Model class.

But with JavaScript being the awesome language that it is, you can change the prototype like this:

Backbone.Model.prototype.idAttribute = "Id";

And now you can totally forget about this, and let Backbone handle IDs properly!

The post Backbone and ASP.NET MVC: Rename the ID attribute appeared first on Martin Normark's blog.

A common practice in many applications today is to not actually delete the entity from the database, but instead mark it as deleted and make sure your data access layer filters out those “deleted” items when selecting.

So I wanted to implement a general “delete” method that would update the DateDeleted column of an entity without touching any other column.

Again I use a detached entity, so the trick is to only mark the DateDeleted column as modified, and not the entire entity.

public bool DeleteEntity(T entity) where T : ModelBase
{
	entity.DateDeleted = DateTime.UtcNow;

	this._databaseContext.Set().Attach(entity);
	this._databaseContext.Configuration.ValidateOnSaveEnabled = false;

	this._databaseContext.Entry(entity).Property(m => m.DateDeleted).IsModified = true;

	int recordsAffected = this._databaseContext.SaveChanges();

	this._databaseContext.Configuration.ValidateOnSaveEnabled = true;

	return recordsAffected == 1;
}

Notice how I disable validation, and then enable it after saving the changes. This is because I don’t want to load the entity before changing DateDeleted. I want to use only the Id, so I want to avoid having to fulfill all validation rules on an entity.

All my model classes derive from the ModelBase class, which looks like this:

public abstract class ModelBase
{
	public ModelBase()
	{
		this.DateCreated = DateTime.UtcNow;
	}

	public DateTime DateCreated { get; set; }

	public DateTime? DateModifed { get; set; }

	public DateTime? DateDeleted { get; set; }
}

To “delete” an entity, I can instantiate an entity, give it an Id, and call the delete method:

Account account = new Account { Id = 123 };

DeleteEntity(account);

The post Entity Framework: Update single column appeared first on Martin Normark's blog.

But sometimes you do need to tweak a few things in order to achieve what you want. For example, I don’t want to load an entity before I can delete it. What’s the point? Say I have a list of Accounts on a webpage, with a shiny delete button that makes an AJAX call to an MVC controller, (or Backbone model, that hits the web backend). In that situation I’ll only have the Id of the entity, which should be enough to delete it.

Attach, Delete

To delete only by Id, you need to create a dummy instance of your model with the Id you wish to delete.

Account account = new Account { Id = 123 };

Then, with EF5 you will have to attach the entity to its DbSet.

this.DbContext.Accounts.Attach(account);

Then mark it as deleted, and save the changes.

this.DbContext.Entry(account).State = EntityState.Deleted;

this.DbContext.SaveChanges();

The post Entity Framework: Delete Entity by Id – Using Detached Instance appeared first on Martin Normark's blog.

The server, being ASP.NET MVC, is the new backend now a days. I’m sure that’s how Microsoft sees it as well, with the release of Web API.

cc by-nc-nd Bruno Monginoux www.photo-paysage.com & www.landscape-photo.net

When using models in Backbone, and specifying the urlRoot setting, Backbone will automatically construct URLs to do CRUD operations against your server. It uses RESTful URLs, and regular ASP.NET MVC controllers are not compatible with those out of the box.

Consider this Backbone model and collection:

var Account = Backbone.Model.extend({
	urlRoot: "/accounts"
});

var AccountCollection = Backbone.Collection.extend({
	model: Account,

	url: "/accounts"
});

When you save a new Account, Backbone will make a POST request to your server expecting to hit your AccountsController. But with regular MVC controllers (non-Web API, that is) the routing won’t succeed, since the default {controller}/Index action only works with the default, parameter less GET request.

You might think that this controller will work:

public class AccountsController : Controller
{
	[HttpGet]
	public JsonResult Index()
	{
		List accounts = new List();
		accounts.Add(new Account { Id = 1, Name = "Account 1" });
		accounts.Add(new Account { Id = 2, Name = "Account 2" });
		accounts.Add(new Account { Id = 3, Name = "Account 3" });

		return Json(accounts, JsonRequestBehavior.AllowGet);
	}

	[HttpGet]
	public JsonResult Index(int id)
	{
		return Json(new Account { Id = id, Name = "Account " + id }, JsonRequestBehavior.AllowGet);
	}

	[HttpPost]
	public JsonResult Index(Account model)
	{
		return Json(model);
	}

	[HttpPut]
	public JsonResult Index(int id, Account model)
	{
		return Json(model);
	}

	[HttpDelete]
	public ActionResult Index(int id)
	{
		return View();
	}
}

But as mentioned before, the default Index routes doesn’t work that way. This won’t even build, since the method signature of Get and Delete are the same.

Route constraints to the rescure

Ideally we want our controller to look like the following:

public class AccountsController : Controller
{
	[HttpGet]
	public JsonResult GetAll()
	{
		List accounts = new List();
		accounts.Add(new Account { Id = 1, Name = "Account 1" });
		accounts.Add(new Account { Id = 2, Name = "Account 2" });
		accounts.Add(new Account { Id = 3, Name = "Account 3" });

		return Json(accounts, JsonRequestBehavior.AllowGet);
	}

	[HttpGet]
	public JsonResult Get(int id)
	{
		return Json(new Account { Id = id, Name = "Account " + id }, JsonRequestBehavior.AllowGet);
	}

	[HttpPost]
	public JsonResult Create(Account model)
	{
		return Json(model);
	}

	[HttpPut]
	public JsonResult Update(int id, Account model)
	{
		return Json(model);
	}

	[HttpDelete]
	public ActionResult Delete(int id)
	{
		return View();
	}
}

So for this to work, we need to point the individual HTTP verbs to their own action. This can be done by adding an HTTP method route constraints, when mapping routes in your RouteConfig (or Global.asax):

routes.MapRoute("Model_GetAll", "{controller}", new { action = "GetAll" }, new { httpMethod = new HttpMethodConstraint("GET") });
routes.MapRoute("Model_GetOne", "{controller}/{id}", new { action = "Get" }, new { httpMethod = new HttpMethodConstraint("GET"), id = @"^\d+$" });
routes.MapRoute("Model_Post", "{controller}", new { action = "Create" }, new { httpMethod = new HttpMethodConstraint("POST") });
routes.MapRoute("Model_Put", "{controller}/{id}", new { action = "Update" }, new { httpMethod = new HttpMethodConstraint("PUT") });
routes.MapRoute("Model_Delete", "{controller}/{id}", new { action = "Delete" }, new { httpMethod = new HttpMethodConstraint("DELETE") });

Now you can code away in Backbone, and always hit the correct MVC controller actions. If you want to avoid this, upgrade your MVC app to MVC 4 and use Web API controllers. They support this out of the box.

The post Backbone.js Compatible Routes for, non-Web API, ASP.NET MVC projects appeared first on Martin Normark's blog.

Of course, you’re the awesome developer and feel like you should be paid 10x as much as the guy sitting next to you. You know that smart developers who gets things done are scarce, very scarce!

And yet, your boss is arguing that your salary should be X because that’s the average salary for a developer in your area, based on some crappy statistics he pulled off of a website just before the meeting.

How To Hit Back

With all the confidence you can get, you must counter argue by saying that you are not an average developer. That you think this company needs more than average people to carry out their goals and deliver products that aren’t average either. And  that he must up his game dramatically, if the negotiations should continue.

By the way…

I have a bunch of invites for Stack Overflow Careers, so if you’re interested ping me on Twitter and I’ll invite you.

The post How To Hit Back When Your Boss Uses Salary Statistics To Negotiate appeared first on Martin Normark's blog.

They made payment integration dead easy with their awesome JavaScript library called Recurly.js that you can use to inject a payment form onto any page with a simple piece of JavaScript, a long with a server generated signature.

But .Net as a platform, and C# as a language is not very well supported by Recurly. They don’t event provide a client library for creating those signatures.

I needed a client library and wrote this simple class that I’ve now uploaded to Nu Get. The package is called RecurlyJS, and the source code is on GitHub.

Enjoy!

The post Use Recurly.js with ASP.NET (MVC), C# with this Nu Get library appeared first on Martin Normark's blog.

You can now easily share logic between controllers without having to inherit from a base controller, that does the common work.

I have a content heavy application that supports a set of layouts. Each layout is rendered by setting the Layout view dynamically, which I do from an ActionFilter. My ActionFilter is fully tested, but when you delegate work to an ActionFilter, you should write a test that ensures the filter is defined on the action.

Not surprisingly, this is very simple and relies on reflection (Download from Gist: https://gist.github.com/2605628):

/// <summary>
/// Verifies the controller action, contains an attribute of the specified attributeType.
/// </summary>
/// <param name="controller">The controller.</param>
/// <param name="action">The action method.</param>
/// <param name="attributeType">Type of the attribute to look for.</param>
/// <returns>Returns true if the attribute was present on the action. Otherwise false.</returns>
public static bool VerifyControllerActionAttribute(this Controller controller, Func<ActionResult> action, Type attributeType)
{
    MethodInfo methodInfo = action.Method;
    object[] attributes = methodInfo.GetCustomAttributes(attributeType, true);
    return attributes.Any(a => a.GetType() == attributeType);
}

And the usage looks like this:

[TestMethod]
public void Index_ContainsTemplateLayoutAttribute()
{
    HomeController controller = new HomeController();
    bool containsAttribute = controller.VerifyControllerActionAttribute(controller.Index, typeof(TemplateLayoutAttribute));
    Assert.IsTrue(containsAttribute);
}

Need an introduction? Watch a video about unit testing ASP.NET and MVC based web apps on Vimeo, published by Typemock.

The post Unit Testing ASP.NET MVC Controller Action contains specific ActionFilter Attributes appeared first on Martin Normark's blog.

The post Make features obvious — forcing usage is even better appeared first on Martin Normark's blog.