:::: MENU ::::

Monday, December 21, 2015

Dependency Injection (DI) is a technique to develop loosely coupled software systems. Although this article won't go into the details of DI as such, the basic idea is this:
Assume that there is a class Class1 that depends on Class2 and Class3 for its functioning. The normal practice is to instantiate the objects of Class2 and Class3 inside Class1 as shown below:
public class Class1
{
   private Class2 objClass2;
   private Class3 objClass3;

    public Class1()
    {
      objClass2 = new Class2();
      objClass3 = new Class3();
    }
   ....
   ....
}
Although this might work as expected it has a problem of its own - there is tight coupling between Class1 and its dependencies (Class2 and Class3). If you wish to replace Class2 and Class3 with some other implementations you need to change the code of Class1 since these objects are created inside the class.
To get away from this dependency you can do the following:
  • Base Class2 and Class3 on some interface.
  • Supply objects of classes implementing the interface (Class2 and Class3 in this case) from external world.
In other words you inject dependencies of a class from the external world. So, Class1 will look like this:
public class Class1
{
    public Class1(ISomeInterface objClass2, 
                  ISomeOtherInterface objClass3)
    {
      ....
    }
}
Ok. Now that you have some idea about DI, let's see how ASP.NET MVC 6 allows you to work with it.
As far as ASP.NET MVC 6 is concerned, a type to be injected is called a service. The ASP.NET MVC 6 dependency injection framework does two basic tasks for you:
  • It instantiates an object of the said service and supplies it to controllers. The dependencies can be injected through constructor injection or through property injection.
  • It handles the lifetime (when to create an object and when to dispose it) of the injected object.
There are four lifetime modes for a service being injected:
  • Singleton : An object of a service is created and supplied to all the requests to that service. So, basically all requests get the same object to work with.
  • Scoped : An object of a service is created for each and every request. So, each request gets its a new instance of a service to work with.
  • Transient : An object of a service is created every time an object is requested.
  • Instance : In this case you are responsible for creating an object of a service. The DI framework then uses that instance in singleton mode mentioned earlier.
Let's see how each of these modes work.
Begin by creating a new ASP.NET MVC 6 project as outlined here. Then add an interface and a class to the Classes (or some other folder of you choice) folder:
public interface IMyServiceInterface
{
    string UniqueID { get; set; }
}

public class MyService:IMyServiceInterface
{
    public string UniqueID { get; set; }

    public MyService()
    {
        this.UniqueID = Guid.NewGuid().ToString();
    }
}
The MyServiceInterface class defines a single property - UniqueID. The MyService class implements IMyServiceInterface. The UniqueID property is set to a new GUID in the constructor of the MyService class. This way you can observe the value of UniqueID to understand the lifetime modes mentioned above.
Then add HomeController and Index view to the project.

Singleton

The DI services and their lifetime modes are registered in the Startup class. So, open the Startup class and modify the ConfigureServices() method as shown below:
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();
    services.AddSingleton();
}
Notice the line marked in bold letters. It uses the AddSingleton() method of the IServiceCollection to register MyService class as a service type. As the name suggests AddSingleton() method registers MyService with singleton mode.
Next, open the HomeController and write the following code to it:
public class HomeController : Controller
{
    private IMyServiceInterface obj;

    public HomeController(IMyServiceInterface obj)
    {
        this.obj = obj;
    }

    public IActionResult Index()
    {
        ViewBag.Obj = this.obj;
        return View();
    }
}
The HomeController constructor takes a parameter of IMyServiceInterface. Since a type that implements this interface is registered with the DI framework, an object of MyService is created and supplied to the constructor. The object reference is stored in a local obj variable for later use.
The Index() action, simply sets a ViewBag property to this injected object. The Index view outputs the value of UniqueID property as follows:

UniqueID of Obj : @ViewBag.Obj.UniqueID

If you run the application your browser should look something like this:
Now open another browser tab and issue another request to /home/index. You will find that both the tabs output the same UniqueID confirming that a singleton object is being created.

Scoped

To change the lifetime mode to Scoped, open Startup class again and change the call as shown below:
 services.AddScoped();
This time the code uses AddScoped() method. After making this change run the application again. Simulate multiple requests as before. This time you will find that each tab displays different UniqueID. This conforms that each request is being supplied with a new object instance.

Transient

To test the transient mode you need to change the Startup class like this:
services.AddTransient();
This time the code uses AddTransient() method to register MyService. Now, to simulate multiple object creation requests within a single request-response cycle modify HomeController as shown below:
public class HomeController : Controller
{
    private IMyServiceInterface obj1;
    private IMyServiceInterface obj2;

    public HomeController(IMyServiceInterface obj1, 
                   IMyServiceInterface obj2)
    {
        this.obj1 = obj1;
        this.obj2 = obj2;
    }

    public IActionResult Index()
    {
        ViewBag.Obj1 = this.obj1;
        ViewBag.Obj2 = this.obj2;
        return View();
    }
}
This time the HomeController declares two variables of IMyServiceInterface. The constructor accepts two parameters of IMyServiceInterface - obj1 and obj2. This is just to simulate multiple object creation requests. The obj1 and obj2 are stored in ViewBag as before.
The Index view outputs the UniqueID from both the objects like this:

UniqueID of Obj : @ViewBag.Obj1.UniqueID

UniqueID of Obj2 : @ViewBag.Obj2.UniqueID

To test the transient mode, run the application. You will find that the two UniqueID values are different even for a single HTTP request.

Instance

In this case you need to create an instance of MyService and register it with the DI framework. You can do so in ConfigureServices() as shown below:
public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc();

    MyService obj = new MyService();
    obj.UniqueID = "013f98e7-bb8b-4d9f-b5a0-04e930db5357";

    services.AddInstance(obj);
}
As you can see, the code creates an object of MyService and assigns its UniqueID property to some GUID. This manually created object instance is then registered with the DI framework using AddInstance() method.
You can run the application as before. You will observe that it works like singleton lifetime mode - the same object instance is supplied to all the requests.

Property Injection Using [FromServices]

The preceding examples used constructor injection to inject MyService instance into the constructor. If you wish you can use an alternative - property injection. To use property injection the controller needs to have public properties of the service type. More importantly they must be decorated with [FromServices] attribute. The following code illustrates how that works:
public class HomeController : Controller
{
    [FromServices]
    public IMyServiceInterface ObjMyService { get; set; }

    ....
    ....
}
The HomeController has a public property ObjMyService. The property is decorated with [FromServices] attribute. The constructor has been removed from the controller. Now the DI framework will instantiate the IMyServiceInterface object according to the lifetime mode configured in ConfigureServices() and assign it to the ObjMyService property. You can then use the ObjMyService wherever you need in the controller.

Tuesday, December 1, 2015

VS 2015 Update 1 is now available for download, including the updated Community edition. The VS 2015 Update 1 Redistribution packages are also available (x86, x64), as well as the Remote Debugging Tools (x86, x64, ARM). For more information, see Brian Harry's blog, the Visual C++ Team blog, and the Visual Studio Team blog.

Compiler and CRT
VS 2015 Update 1 includes a new version of the C/C++ compiler (19.00.23506). There is also a new version of the C/C++ Runtime (14.0.23506).

Note that VS 2015 can target Windows 10, Windows 8.x, Windows 7 Service Pack 1, Windows Vista Service Pack 2, and optionally Windows XP Service Pack 3. The Visual C++ 2015 REDIST does not support Windows 7 RTM, Windows Vista RTM, Windows Vista Service Pack 1, Windows XP RTM, Windows XP Service Pack 1, or Windows XP Service Pack 2 as these platforms are all outside their support lifecycle. See KB2661358.

Windows 10 SDK: VS 2015 Update 1 includes an updated Windows Tools 1.2 with the Windows 10 SDK for Version 1511 (10.0.10586). As before, this is an optional install.

.NET: There is now a 4.6.1 release including a number of Windows Presentation Foundation (WPF) improvements including a D3DImage for Direct3D 11 available on GitHub.

When it comes to writing good code in web development it is easy to get lost in the quantity of resources you find online. There are some basics that everyone knows or should know and there are some more specific ones.
Are you able to tell me right now that you sure you follow these practices ? Probably not. You probably have the intuition that you do and you are certainly writing your code with them in mind but you cannot be sure you always respect them.
As I said, there are a lot of different resources on the web. It is not easy to know all of them. It is not easy to follow all of them. And it is sure not easy to be sure you did it correctly.
This is why we decided to create the Best Practices plugin in Vorlon.js. It is a way for you to automatically get hints and recommandations about how you could improve your code. The current list of practices and scans have been created from our own experience. It is extensible and you can add your own rules to contribute to this plugin and make it more accurate and comprehensive. :)
A great thanks to Guillaume Leborgne and Mehdi Lahlou for their strong work on this!

How to use the best practices plugin

First of all, you need to setup a Vorlon.js environment. You can follow the documentation we provide here :http://vorlonjs.com/documentation/#vorlonjs-server
Once you have an up and running vorlon.js server and your website is connected to it, hit the “play” button on the Best Practice tab. It will run dynamic and static tests on the page you are currently debugging and the resources linked to it (JavaScript files, CSS files, etc.)
The above video shows you the kind of result you get when using this plugin. All the recommendations are organized into 4 categories, Web Standards, Accessibility, Performances, Mobile Web.
Let’s have a look at some of the rules you get in each of these categories.

1. Web Standards

There are a lot of common mistakes we can do in this area. Sometimes, it is not even a mistakes. Take the JavaScript libraries you use for instance: how frequently do you go and check if the version you are referencing is obsolete or not ? Or consider the CSS prefixes problematic: are you sure you always add all the vendor prefixes? That could be a good idea to make sure your site works correctly on the widest range of computers. Do you have code which does browser detection ? You should change it to feature detection. Etc. etc.
This section gives your insights about what you can improve in this area:
  • Avoid browser detection: tells you if you have code calling navigator.userAgent 
  • Avoid browser specific content: is checking whether your website is sending a different content for some browsers
  • Avoid conditionnal comment: Conditional comments are not the best way to adapt your website to target browser, and support is dropped for IE > 9.
  • Incorrect use of css fallback: validates that all the css rules present in the CSS file are really there in the computed styles. This is a dynamic check and the result might be true or false depending on the browser you use.
  • Incorrect use of prefixes: this one is performing a static scan on your CSS files to ensure you are always using all the vendor prefixes
  • Object and embed: the modern web is only about web languages not plugins, activeX and other embeded objects. This validates that your website does not include one
  • Update JavaScript libraries: checks if all the JS files you are using are considered by their creators as not obsolete
  • Use modern doctype: Modern doctype like are better for browser compatibility and enable using HTML5 features.

2. Accessibility

Following web standards does not guarantee you that your web page is easily accessible. Accessibility is something the Vorlon.js team is really concerned about.
A lot of work is done currently for sometimes now about this by great people. One exemple is the aXe product created bydeque. It is an open source tool which gives you a gigantic list of advices about your website. They go deep in the analysis and can for instance tell you that a specific element has insufficient color contrast for someone visually impaired to see properly. This is really awesome work and we worked with the team at deque to integrate this into this plugin.
Note : this integration is not available in the npm version of Vorlon.js yet but you can get it form the dev branch in the github repository.
There are too much rules in there for me to be able to list them all but here are the fixed one:
  • Form elements must have labels: for them to be understandable by automated web readers
  • Images must have alternate text: this one is listing you all the tag which does not contain the alt attribute.
  • Use aria attributes
All the aXe rules are displayed only if they are in a failed state :

3. Performances

You can follow some simple rules to get better performances for your website.
  • Encore static content: tries to determine if you are using gzip or deflate encoding to reduce de network bandwith
  • Minify static files: checks if you used a minification process to reduce the size of your CSS and JavaScript files
  • Try bundling your files: simple algorithm that checks if you created a single file for all your scripts to reduce HTTP requests

4. Mobile Web

When it comes to mobiles, a lot of web devs forget to add the correct elements and information to take it correctly into account.
  • define platform icons: This is really not mandatory but it gives the user a better experience when they are pinning your websites
  • use meta viewport: Use meta viewport tag to choose how your website will get scaled on smaller devices like phones. Define at least
  • use responsive approaches: Even if your website target only certain devices, you may have users with unexpected devices or screen ratio.

Your turn !

The plugin provides for now somes basic rules. We really hope this will be completed by new rules that anyone in the community can create. Do not hesitate to add yours and create a pull request in the Vorlon.js repo.