Cleaning Up Deep Callback Nesting With Node's EventEmitter by Rob Conery

One problem people face when starting out with Node (and Javascript in general) is handling the asynchronous, deep callback nesting issue. EventEmitters help fix that.

The Registration Problem

Consider this: you want customers to register with your site. When they do, a number of things need to happen:

1. The information needs to be validated
2. The customer record inserted
3. An email sent to say "thank you"

In a typical scenario, there's probably more - but let's use this for now.

You might know straight away how to do this in Ruby or C# - but how would you handle this with Node and Javascript?## O Christmas Tree

This is some code that you might see in a Customers module:

Yuck.

This code is not only hideous-looking, it's also synchronous and a nightmare to maintain. Node allows you to do this much better with EventEmitters. Let's see how to use Events to clean this code up.

Emit It

There are two ways to do this: encapsulate the eventing, or make your entire object an EventEmitter through inheritance. I'll do the latter.

The first thing to do is reference Node's event module and the util module as well - it has some helpers we'll need. Then we rewire the module to handle the events - I'll explain in a second, but here's the final code:

So what's going on here? Well first - there are no more callbacks - we don't need them! We have events to listen to.

I'm using Node's built-in EventEmitter object to "graft" on some functionality to my Customer object. Javascript doesn't have inheritance, per se, but you can take the prototype of one function and pop it on another.

Node helps you with this using the "util" library. On line 42 we're telling the util to push the prototype from events.EventEmitter onto our Customer function. Notice that this is a function, not an instance of a function as I had in the first example above.

Next, on line 7, I had to invoke the "base" constructor to be sure that I don't miss any internal instancing or setting of values. Turns out for EventEmitters you don't need to do that and you can omit this line - but it's safe to just do it, no matter what.

In the body of each method I'm simply "emitting" an event to all listeners (there's obviously some code missing here - pretend that I have an insert routine and so on). I can emit an event for whatever happens along the way - a successful validation fires "validated", a failure might fire "validationFailed". This frees up our code to do what it needs to do and no more, making it much cleaner and clearer.

On line 29 I've added a final event trigger if everything works out: "successfulRegistration". This is what calling code will really be interested in the most - either that or "failedRegistration" - and we pass along the customer record (more on that in a second).

On lines 35 through 38 we've implemented a bit of workflow. This doesn't need to be inside the Customer function - you can arrange these events wherever and however you like. The calling code can remove every event listener and replace it with its own if it wanted to reorganize the flow here.Speaking of calling code, here's what it might look like:

You hook into the events, then run register() and respond as needed.

All Over The Place

Node is built on top of EventEmitters - you'll find them everywhere. Understanding them is key to writing cleaner code that's more functional and maintainable - and it also helps keep things asynchronous.

n the first example, we had a synchronous drop all the way down - even though we were using callbacks. Our code above isn't synchronous at all - we've hooked into an event and when Node is ready, it will process the emitted event callback.

Neat stuff!

Domain Specific Languages by Martin Fowler (with Rebecca Parsons)

Domain Specific Languages (DSLs) have been around since I've been in computing, but it's hard to find much information about how to work with them. DSLs are small languages, focused on a particular aspect of a software system. You can't build a whole program with a DSL, but you often use multiple DSLs in a system mainly written in a general purpose language.

DSLs come in two main forms: external and internal. An external DSL is a language that's parsed independently of the host general purpose language: good examples include regular expressions and CSS. External DSLs have a strong tradition in the Unix community. Internal DSLs are a particular form of API in a host general purpose language, often referred to as a fluent interface. The way mocking libraries, such as JMock, define expectations for tests are good examples of this, as are many of the mechanisms used by Ruby on Rails. Internal DSLs also have a long tradition of usage, particularly in the Lisp community.

People find DSLs valuable because a well-designed DSL can be much easier to program with than a traditional library. This improves programmer productivity, which is always valuable. In particular it may also improve communication with domain experts, which is an important tool for tackling one of the hardest problems in software development. CSS is an excellent example of this, most people who program CSS don't consider themselves to be programming. Despite this, however, I don't generally think that end-users will usually write in DSLs directly - it's the communication enhancement that's important.

Although DSLs have been around for a long time, the lack of knowledge of how to program with them is a significant barrier - which is exactly why I've worked on this book. The books provides techniques to develop both internal and external DSLs, giving you both the information to choose between them and a good package of information to begin your work. I also stress the importance of layering a DSL over a library, so that you usually build both together. There's also material on code-generation, which is an occasionally essential part of working with a DSL.

Like P of EAA this book is a Duplex Book, providing both a narrative to learn about DSLs and a reference book for the details, so don't be scared by the high page count. You can get a good grasp of the topic by reading the narrative section (142 pages) and use the rest as a reference to dip into when you need it.

Electronic copies of this book are available. Amazon has a version for kindle. InformIT has epub and pdf versions. Apple has an epub version in the ibookstore.

SQL SERVER – How to easily work with Database Diagrams by PINAL DAVE

Databases are very widely used in the modern world. Regardless of the complexity of a database, each one requires in depth designing. To practice along please Download dbForge Studio now. 

The right methodology of designing a database is based on the foundations of data normalization, according to which we should first define database’s key elements – entities. Afterwards the attributes of entities and relations between them are determined.

There is a strong opinion that the process of database designing should start with a pencil and a blank sheet of paper. This might look old-fashioned nowadays, because SQL Server provides a much wider functionality for designing databases – Database Diagrams.

When using SSMS for working with Database Diagrams I realized two things – on the one hand, visualization of a scheme allows designing a database more efficiently; on the other – when it came to creating a big scheme, some difficulties occurred when designing with SSMS.

The alternatives haven’t taken long to wait and dbForge Studio for SQL Server is one of them. Its functions offer more advantages for working with Database Diagrams.

For example, unlike SSMS, dbForge Studio supports an opportunity to drag-and-drop several tables at once from the Database Explorer. This is my opinion but personally I find this option very useful.

Another great thing is that a diagram can be saved as both a graphic file and a special XML file, which in case of identical environment can be easily opened on the other server for continuing the work.

During working with dbForge Studio it turned out that it offers a wide set of elements to operate with on the diagram.

Noteworthy among such elements are containers which allow aggregating diagram objects into thematic groups.

Moreover, you can even place an image directly on the diagram if the scheme design is based on a standard template.

Each of the development environments has a different approach to storing a diagram (for example, SSMS stores them on a server-side, whereas dbForge Studio – in a local file).

I haven’t found yet an ability to convert existing diagrams from SSMS to dbForge Studio. However I hope Devart developers will implement this feature in one of the following releases.

All in all, editing Database Diagrams through dbForge Studio was a nice experience and allowed speeding-up the common database designing tasks.

Download dbForge Studio now.

Reference: Pinal Dave (http://blog.sqlauthority.com)

Combining JavaScript with Other Languages on the Web

Combining JavaScript with Other Languages on the Web

Summary
Alon Zakai discusses writing and deploying web applications that use both handwritten JavaScript and another language like C++ that has been compiled into JavaScript, presenting the advantages of that approach, open source tools like Emscripten and Embind that enable it, asm.js optimizations which let it run at near-native speeds, and several real-world examples of such projects.

Bio

Alon Zakai is a researcher at Mozilla, working on techniques for compiling code to the web platform. In 2010 Alon founded the Emscripten open source project which utilizes LLVM to compile C and C++ to JavaScript, with the goal of allowing existing codebases to be automatically ported to standard web technologies.

Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.

Programming ASP.NET MVC 4

Appendix C. Best Practices

This book explains a multitude of topics in varying degrees of detail and offers a lot of advice. However, it is sometimes difficult to judge just how important any given piece of information is in the context of a long, technical description about it.

This chapter calls out many of the common best practices noted throughout the book in a single list, making it easier to read through the list and validate very quickly whether you are following the popular patterns and practices set forth in this book.

Use the NuGet Package Manager to Manage Dependencies

The NuGet package manager is a great boon to developers and teams alike. Instead of spending your time getting up and running and checking to see if the projects that your application depends on have released new versions, let NuGet handle all of that for you!

If your organization has several teams that share common libraries, consider creating custom NuGet packages for those shared libraries and hosting a custom NuGet repository to provide more effective distribution and versioning.

Depend On Abstractions

Abstractions encourage loosely-coupled systems with a healthy separation of contracts and implementations. Abstractions are easily interchanged which not only provides easier maintenance, but is also crucial to unit testing.

Avoid The New Keyword

Any time you employ the new keyword to create a new instance of a concrete type you are — by definition — not depending on an abstraction. Though this is often not a problem at all (e.g. new StringBuilder(), new List(), etc.), take a moment any time you use the new keyword to consider if the object you are creating might be better expressed as a dependency to be injected. Let another component create it!

Avoid Referring To HttpContext Directly (use HttpContextBase)

ASP.NET MVC (and later, .NET 4) introduced System.Web.Abstractions, a set of abstractions over many of the core parts of the ASP.NET Framework. The "depend on abstractions" advice extends to these classes as well. In particular, one of the most often referenced objects in ASP.NET development is HttpContext — prefer using the HttpContextBase abstraction instead.

Avoid "Magic Strings"

"Magic strings" — crucial, yet arbitrary string values — may be convenient and in many situations even required, however they have many issues. Some of the biggest issues with magic strings are that they:

1)  don't have any intrinsic meaning  (e.g. it's difficult to tell how or if one "ID" relates to another "ID")
2)  are easily broken with misspelling or case sensitivity
3)  don't react well to refactoring
4)  promote rampant, pervasive duplication

Here are two examples, the first using magic strings to access data in a ViewData dictionary, and the second refactored example with that same data in a strongly-typed model:

Using magic strings. 

    First Name:
    @ViewData["FirstName"]

Using a strongly-typed model. 

    First Name:
    @Model.FirstName

Magic strings carry the allure of being very simple to use when you introduce them, but that ease of use often comes back to bite you later when it comes time to maintain them.

Prefer models Over ViewData

As the preceding example shows, the ViewData dictionary is one of the most tempting places to leverage magic strings in an ASP.NET MVC application. However, strongly-typed Presentation Models can be a handy tool to avoid assigning and retrieving data directly to and from the ViewData dictionary.

Do Not Write HTML In "back-end" Code

Follow the practice of separation of concerns: it is not the responsibility of controllers and other "back-end code" to render HTML. The exceptions here, of course, are UI helper methods and classes whose only job is to help the views render code. These classes should be considered part of the view, not "back-end" classes.

Do Not Perform Business Logic In Views

The inverse of the previous practice is true as well: views should not contain any business logic. In fact, views should contain as little logic as possible! Views should concentrate on how to display data that they have been provided, not take action on that data.

Consolidate Commonly-used View Snippets With Helper Methods

The notion of "user controls," "server controls," and simply "controls" in general is very widespread… and for good reason. These concepts help consolidate commonly-used code and logic in a central location to make it easier to reuse and maintain. ASP.NET MVC is not control-driven, however — instead, it relies on the "helper method" paradigm in which methods do the work that controls once did. This can pertain to an entire section of HTML (what we’re used to calling a "control"), or even as simple as strongly-typed access to a commonly-referred URL. For example, you may notice many of the same references to the "Membership Page" (~/membership) like so:

@Html.ActionLink("Membership", "Index", "Membership", [...])

You can instead consolidate this call (and eliminate the magic strings!) by turning it into a helper method:

@Html.MembershipLink()

Prefer Presentation Models Over Direct Usage Of Business Objects

In general, try to avoid allowing changes to the business model to directly affect the view. Presentation Models help with this.

Encapsulate "if" Statements With HTML Helpers in Views

Integrating code and markup is quite powerful; however, it can get quite messy. Consider the following (relatively simple) if-else statement:

Index.cshtml. 

@if(Model.IsAnonymousUser) {
    
} else if(Model.IsAdministrator) {
    
} else if(Model.Membership == Membership.Standard) {
    
} else if(Model.Membership == Membership.Preferred) {
    
}

That’s quite obscure code for rendering out essentially the same markup with the exception of one part (the URL). Consider this approach instead:

UserHtmlHelperExtensions.cs. 

public static string UserAvatar(this HtmlHelper helper)
{
    var user = helper.ViewData.Model;

    string avatarFilename = "anonymous.jpg";

    if (user.IsAnonymousUser)
    {
        avatarFilename = "anonymous.jpg";
    }
    else if (user.IsAdministrator)
    {
        avatarFilename = "administrator.jpg";
    }
    else if (user.Membership == Membership.Standard)
    {
        avatarFilename = "member.jpg";
    }
    else if (user.Membership == Membership.Preferred)
    {
        avatarFilename = "preferred_member.jpg";
    }

    var urlHelper = new UrlHelper(helper.ViewContext.RequestContext);
    var contentPath = string.Format("~/content/images/{0}", avatarFilename);
    string imageUrl = urlHelper.Content(contentPath);

    return string.Format("", imageUrl);
}

Index.cshtml (and everywhere else you need the user’s avatar). 

   @Html.UserAvatar()

Not only is this cleaner, it’s also more declarative and moves this logic into a central location so that it may be more easily maintained. For instance, if the requirements change and the site needs to support custom avatars, the Html.UserAvatar helper method can be modified in one place.

Prefer Explicit View Names

A majority of the ASP.NET MVC controller action code samples call the View() method without specifying a view name. This is suitable for simple demo code, however when tests or other action methods begin calling each other, the detriments to this approach become clear. When no view name is specified, the ASP.NET MVC Framework defaults to the name of the action that was originally called. Thus, calling the Index action in the following example will attempt to locate a view named "Index.cshtml" — a view that probably doesn’t exist (but "List.cshtml" certainly does!):

EmployeeController.cs. 

public ActionResult Index()
{
    return List();
}

public ActionResult List()
{
    var employees = Employee.GetAll();
    return View(employees);
}

If the List action is modified to call the View() method with a specific view name (as shown below), everything works fine.

public ActionResult List( )
{
    var employees = Employee.GetAll();
    return View("List", employees);
}

Prefer Parameter Objects Over Long Lists Of Parameters

This advice is not specific to ASP.NET MVC - long parameter lists are commonly considered a "code smell" and should be avoided whenever possible. Additionally, ASP.NET MVC’s powerful Model Binders make following this advice incredibly easy. Consider the two contrasting snippets:

Long Parameter List. 

public ActionResult Create(
        string firstName, string lastName, DateTime? birthday,
        string addressLine1, string addressLine2,
        string city, string region, string regionCode, string country
        [... and many, many more]
    )
{
    var employee = new Employee( [Long list of parameters...] )
    employee.Save();
    return View("Details", employee);
}

Parameter Object. 

public ActionResult Create(Employee employee)
{
    employee.Save();
    return View("Details", employee);
}

The Parameter Object example is much more straight-forward, and leverages the ASP.NET MVC Framework’s powerful Model Binders and model validation to make this code much safer and easier to maintain.

Encapsulate Shared/Common Functionality, Logic, And Data With Action Filters Or Child Actions (Html.RenderAction)

Every website of any significant complexity will have common elements across multiple (or perhaps all) pages in the application. A global website navigation menu — the kind that appears on every single page in the site - is a canonical example of this type of globally-applied logic and content. The data for these common elements needs to come from somewhere, yet explicitly retrieving the data in every controller action would create a maintenance nightmare. Action Filters and/or child actions (via the Html.RenderAction method) provide a central location to hold this kind of logic.

Consider the following layout snippet (cut from the larger layout page) which renders navigation items in a list:

    @foreach (var menuItem in ViewData.SingleOrDefault()) {

            @Html.RouteLink(menuItem.DisplayName, menuItem.RouteData)
        
}

The NavigationMenu ViewData object needs to come from somewhere. Since they can be configured to execute prior to every controller request, Action Filters make an excellent candidate to populate View Data with globally-required data like this. Here is the Action Filter that populates the NavigationMenu data required in the previous example:

public class NavigationMenuPopulationFilter : ActionFilterAttribute
{
    private readonly INavigationDataSource _dataSource;

    public NavigationMenuPopulationFilter(INavigationDataSource dataSource)
    {
        _dataSource = dataSource;
    }

    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        NavigationMenu mainMenu = _dataSource.GetNavigationMenu("main-menu");
        filterContext.Controller.ViewData["MainNavigationMenu"] = mainMenu;
    }
}

This Filter is pretty straight-forward — it gets the correct navigation menu data model from some data source and adds it to the View Data collection prior to executing the requested action. From this point on, any component that requires it can retrieve the navigation menu from View Data.

Prefer grouping Actions into Controllers based on how they relate to business concepts

For example, consider creating a CustomersController to hold the actions related to dealing with Customers.

Avoid grouping Actions into Controllers based on technical relation

For example, avoid creating the AjaxController to contain all of the AJAX Actions that your site exposes. Instead, group these actions together with their related concepts. For example, the AJAX actions that provide Customer data or partial views should be in the CustomersController with all of the other customer-related actions.

Prefer Placing Action Filters At The "highest appropriate level"

Most Action Filter attributes can be applied at either the method (Action) or class (Controller) level. When an attribute applies to all actions in a controller, prefer placing that attribute on the controller itself rather than on each individual class. Also consider whether or not the attribute may be appropriate further up the controller’s dependency chain (i.e., on one of its base classes) instead.

Prefer multiple views (and/or Partial views) Over Complex If-Then-Else Logic That Shows And Hides Sections

The Page Controller pattern of Web Forms encourages posting back to the same page, possibly showing or hiding certain sections of the page depending on the request. Due to ASP.NET MVC’s separation of concerns, this can often be avoided by creating separate views for each of these situations, lowering or eliminating entirely the need for complex view logic. Consider the following example:

Wizard.cshtml. 

@if(Model.WizardStep == WizardStep.First) {
    
} else if(Model.WizardStep == WizardStep.Second) {
    
} else if(Model.WizardStep == WizardStep.Third) {
    
}

Here the view is deciding which step of the Wizard to display, which is dangerously close to business logic! Let’s move this logic to the Controller where it belongs and split this view into multiple views:

WizardController.cs. 

public ActionResult Step(WizardStep currentStep)
{
    // This is simple logic, but could be MUCH more complex!
    string view = currentStep.ToString();

    return View(view);
}

First.cshtml. 

Second.cshtml. 

Third.cshtml. 

Prefer The Post-Redirect-Get Pattern When Posting Form Data

The Post/Redirect/Get (PRG) pattern is a common design pattern for web developers to help avoid certain duplicate form submissions and allow user agents to behave more intuitively with bookmarks and the refresh button. Due to the Page Controller nature of Web Forms in which developers are usually required to post back to the same page for all actions in a particular context (e.g. display employee data so that it may be edited and re-submitted), the PRG pattern is not used as much in Web Forms environments. Because ASP.NET MVC separates actions into separate URLs it is easy to run into trouble with update scenarios. For instance,

EmployeeController.cs. 

public class EmployeeController : Controller
{
    public ActionResult Edit(int id)
    {
        var employee = Employee.Get(id);

        return View("Edit ", employee);
    }

    [AcceptVerbs(HttpVerbs.Post)]
    public ActionResult Update(int id)
    {
        var employee = Employee.Get(id);

        UpdateModel(employee);

        return View("Edit", id);
    }
}

In this example when a user posts to the Update action, though the user will be looking at the "Edit" view as desired, the resulting URL in their browser will be "/employees/update/1". If the user refreshes the page or bookmarks a link to that URL, etc. subsequent visits would update the employee information again or even not work at all. What we really want to happen in the Update action is to update the Employee information and then redirect the user back to the Edit page so that they are back to the original "Edit" location. In this scenario, the PRG pattern may be applied thusly:

EmployeeController.cs (partial, showing only the changed Update action). 

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Update(int id)
{
    var employee = Employee.Get(id);

    UpdateModel(employee);

    return RedirectToAction("Edit", new { id });
}

Though it’s a subtle change, switching from the View() method to the RedirectToAction() method will produce a client-side redirect (as opposed to a "server-side redirect" in the original example) after the Update method has finished updating the employee, landing the user on the proper URL: "/employees/edit/1".

Prefer Startup Tasks Over Logic Placed In Application_Start (global.asax)

Most ASP.NET MVC demos will advise modifying the Application_Start method in the Global.asax file in order to introduce logic that will execute when the application starts. While this is certainly the easiest and most straight-forward approach, the WebActivator framework provides the concept of startup tasks. These tasks are easy to implement and are automatically discovered and executed during the application startup. These tasks help provide cleaner code and encourage proper adherence of the Single Responsibility principle.

Prefer Authorize Attribute Over Imperative Security Checks

Traditionally, authorization control resembles the following:

public ActionResult Details(int id)
{
    if (!User.IsInRole("EmployeeViewer"))
        return new HttpUnauthorizedResult();

    // Action logic
}

This is a very imperative approach, and makes it difficult to implement application-wide changes. The ASP.NET MVC AuthorizeAttribute provides a simple and declarative way to authorize access to actions. This same code may be rewritten as:

[Authorize(Roles = "EmployeeViewer")]
public ActionResult Details(int id)
{
    // Action logic
}

Prefer Using The Route Attribute Over More Generic Global Routes

Of course, the most specific route is one that maps directly to one action and one action only.

Consider Using An Anti-Forgery Token To Avoid CSRF Attacks

For form posts where security is a concern, ASP.NET MVC provides measures to help deter certain kinds of common attacks. One of these measures is the Anti-forgery Token. The Token has both server- and client-side components.

Client Side: Call the Html.AntiForgeryToken helper method inside your form. 

@using(Html.Form("Update", "Employee")) {
    @Html.AntiForgeryToken()
    
}

Server Side: Apply the ValidateAntiForgeryTokenAttribute to the form post action. 

[ValidateAntiForgeryToken]
[AcceptVerbs(HttpVerbs.Post | HttpVerbs.Put)]
public ActionResult Update(int id)
{
    // Process validated form post
}

This code will insert a user-specific token in a hidden field on your form and validate that token on the server side prior to executing any further processing of the data being posted.

Consider the AcceptVerbs Attribute To Restrict How Actions May Be Called

Many Actions rest on a number of assumptions about how and when they will be called in the context of an application. For instance, one assumption might be that an Employee.Update action will be called from some kind of Employee Edit page containing a form with the Employee properties to post to the Employee.Update action in order to update an Employee record. If this action is called in an unexpected way (e.g. via a GET request with no form posts), the action will probably not work, and in fact may produce unforeseen problems.

The ASP.NET MVC framework offers the AcceptVerbs attribute to help restrict action calls to specific Http Methods. Thus, the answer to the aforementioned Employee.Update scenario would be:

[AcceptVerbs(HttpVerbs.Post | HttpVerbs.Put)]
public ActionResult Update(int id)

Applying the AcceptVerbs attribute in this way will restrict requests to this action only to those made specifying the POST or PUT HTTP Methods. All others (e.g. GET requests) will be ignored.

Consider Output Caching

Output caching is one of the easiest ways to get additional performance from a web application. Caching requests in which little or no content has changed since the previous request is a quick way to speed up your request times. The ASP.NET MVC framework offers the OutputCacheAttribute to accomplish this task. This attribute mirrors the Web Forms output caching functionality and accepts many of the same properties.

Consider Removing Unused View Engines

ASP.NET MVC registers both the Web Forms and Razor View by default, which means that the View Locator will try to search the view locations for both Web Forms and Razor views. This makes it possible to use either (or both!) types of views in your application.

However, for consistency’s sake most teams choose one type of view and use that type exclusively throughout their application, making it a bit wasteful for the ASP.NET MVC View Locator to look for views of the type that aren’t being used. For example, if you choose to only use Razor views in your application, the View Locator will continue to search for Web Forms views even though you know that it will never find one.

Luckily, you can avoid this unnecessary overhead and slightly optimize your application by unregistering the view engine that you are not using.

Removing the Web Forms View Engine shows how to unregister the Web Forms View Engine (leaving only the Razor View Engine):

Removing the Web Forms View Engine. 

var viewEngines = System.Web.Mvc.ViewEngines.Engines;

var webFormsEngine = viewEngines.OfType().FirstOrDefault();

if (webFormsEngine != null)
    viewEngines.Remove(webFormsEngine);

Add a comment

Just execute this snippet during the application’s start-up phase and it will no longer waste time looking for views that aren’t there!

Consider Custom ActionResult For Unique Scenarios

The ASP.NET MVC Request Pipeline has a deliberate separation of concerns in which each step in the process completes its task and no more. Each step does merely enough to provide the subsequent tasks with enough information to do what they need to do. For instance, a controller action that decides a view should be rendered to the client does not load up a view engine and order it to execute the view, it merely returns a ViewResult object with the information that the Framework needs to take the next steps (most likely loading a view engine and executing the view!).

When it comes to results of controller actions, declarative is the name of the game. For instance, the ASP.NET MVC Framework provides an HttpStatusCodeResult with a StatusCode property, but it also goes one step further to define a custom HttpStatusCodeResult named HttpUnauthorizedResult. Though the following two lines are effectively the same, the latter provides a more declarative and strongly-typed expression of the controller’s intent.

  return new HttpStatusCodeResult(HttpStatusCode.Unauthorized);

  return new HttpUnauthorizedResult();

When your actions produce results that don’t fit the "normal results", take a moment to consider whether returning a custom Action Result may be more appropriate. Some common examples include things like RSS feeds, Word documents, Excel spreadsheets, etc.

Consider Asynchronous Controllers For Controller Tasks That Can Happen In Parallel

Parallel execution of multiple tasks can offer significant opportunities to enhance the performance of your site. To this end, ASP.NET MVC offers the AsyncControllerbase class to help make processing multi-threaded requests easier. When creating an action with processor-intensive logic, consider whether that action has any elements that may be safely run in parallel. See Chapter 11, Parallel, Asynchronous, and Real-Time Data Operations for more information.

Source: Programming ASP.NET MVC 4