Protocol Buffers in C#

Installation
Protocol Buffers can be installed via Nuget,

 PM> Install-Package Google.ProtocolBuffers  

Or search for Protocol Buffers, there is also a Protocol buffers lite package that is smaller and does not use relection (better for some lighter platforms like mono). Note: an option must be set in the .proto file to compile the proto for use with the lite package.

Tools
As well as installing the protocol buffers library this will also download the tools required to compile .proto files and generate C# files from them. The tools will be located where the nuget package was installed to.

.proto
A .proto file will be required to generate the required files for usage. This example .proto defines a message called TestMessage with 3 properties. The package is used like a namespace and will also be used to generate the namespace of the classes in C#.

 syntax = "proto2";  
   
 package test_proto;  
   
 message TestMessage  
 {  
   required int32 Id = 1;  
   required string Name = 2;  
   optional string Details = 3;  
 }  

For more information on defining a .proto file see the protocol buffer v2 spec.

Protoc
To compile a .proto file locate protoc.exe in the tools dir and run it with the following parameters.

 protoc -oitem test.proto  

where item is the name of the output file and test.proto the name of the .proto file. This outputs a compiled version of the .proto file.

ProtoGen
The next step is to generate the .cs files that will contain the generated code that can be used to create and serialize the data.

 .\ProtoGen.exe item  

This should generate a .cs file containing everything you need to read/write to the protocol buffers.

Serialization

 var builder = new TestMessage.Builder();  
   
 builder.Id = 2;  
 builder.Name = "Test";  
 builder.Details = "Some Detials";  
   
 var message = builder.Build();  
   
 var bytes = message.ToByteArray();  

You must create a builder as messages are immutable (Each message generates and internal Builder class), a message can be turned back in to a builder easily wit the ToBuilder() method.

Deserialization

 var builder = new TestMessage.Builder();  
 builder.MergeFrom(bytes);  
 var message = builder.Build();  

You could just read the data from the builder if you wish.

Other Methods
message.ToJson() & message.ToXml()
These can be used to visualize the message in other formats.

message.WriteTo(Stream stream)
This is used to write the bytes to a stream.

References
https://developers.google.com/protocol-buffers/
https://developers.google.com/protocol-buffers/docs/reference/proto2-spec
https://github.com/google/protobuf

Protocol Buffers

Protocol Buffers are a language-neutral, platform-neutral extensible mechanism for serializing structured data (official site).

In short protocol buffers are googles in house binary serialization format, designed to serialize small messages fast and with a small data size.

Where to use them
Protocol buffers are great when you need fast serialization and a small payload (where efficiency/speed is important). They are not so good when data formats are likely to change as this will mean you need to discard and recreate schemas and drop backwards compatibility or have multiple schemas for different versions.

Pros

• Fast
• Small Payload
• Many cross platform implementations (c++, Java, C#, python, JS)
• Generators a provided to generate data access classes

Cons

• Schema Enforced (Need to define .proto file)
• More complicated API than some other serializers

Proto Format
Protocol Buffer messages are first defined in a .proto file using the proto language. This can then be used to generate data access objects for your language of choice.

 message Boiler  
 {  
   required string BoilerId = 1;  
   required int32 TableNumber = 2;  
   required string TableName = 3;  
   required string BoilerData = 4;  
   required string BrandName = 5;  
   required string Qualifier = 6;  
   required string ModelName = 7;  
 }  

Fields are described with options (required, optional, repeated, etc..) followed by Type (int32, int64, string), field name then = and an Id number that must be unique. For more information read the v2 spec.

Proto3
The current version is proto2, but Proto3 is current in alpha and being developed (Source code on GitHub) The update will include a new version of the .proto syntax.

Binary vs Text Serialization

 {  
  "Id": "21",  
  "Name": "Test User",  
  "address": {  
   "streetAddress": "Test Street",  
   "city": "Birmingham"  
  }  
 }  

Some formats serialize to text (JSON, XML, etc..) this can be really useful if you need to quickly view and edit the documents without special tooling. Binary serializations will require a tool that can read the document before you can begin to read and manipulate the data. Binary serializations will normally be smaller and more efficient though.

References
https://developers.google.com/protocol-buffers/
https://github.com/google/protobuf
https://developers.google.com/protocol-buffers/docs/reference/proto2-spec

Encapsulation

Encapsulation
Encapsulate - "To enclose or be enclosed in or as if in a capsule". [the free dictionary]

In software

Encapsulation is the practice of having classes/objects not expose their data but expose methods to act upon the data. It also relates to how we choose to put methods and data into classes (Putting data with the relevant methods that use it).

There are many ways we can choose to decompose systems into objects but encapsulation is an effective way of making systems easier to understand and maintain. By restricting access to data we can change the internals of a class/module without requiring changes in the code that uses that class/module.

Example

I have a class “Person”

 public class Person  
 {  
   public string FirstName { get; set; }  
   public string LastName { get; set; }  
 }  

Now take the following method:

 public string FullName(Person person)  
 {  
        return person.FirstName + person.LastName;  
 }  

If this method is not in the Person class the class must expose the firstname and lastname data for this method to work. So any other piece of code then has access to firstname and lastname and can use it. This means that if at a later point you decide to store the person’s name as just a fullname string you must change code that is outside of the person class. If this method is part of the person class you only have to update the person class and as long as its public interface is well designed and not affected by the change you should not have to change any other classes.

Design

By carefully thinking about how we compose our classes we can hide the details (implementation) from the outside world, this can be a massive advantage when maintaining large systems as we can completely rewrite the internals of a class and have it not affect the rest of the system. When classes are encapsulated well it can lead to a better conceptual model (set of classes that represent the system), and often a better set of abstractions making the system easier to code against.

How to achieve 

You can use Getters and Setters to make it easier to encapsulate data, in .net an auto property can achieve this quickly. This will let you change the data later and still use the same property. Generally I would prefer using methods to act upon a class though.

Put methods in the same class as the data they are operating on, this should help achieve cohesion and make modification easier later.

Avoid
Classes exposing their data and their internal workings, this can even include the way you design your methods. Sometimes you can encapsulate how the object works by avoiding sharing of implementation details. For example return amount of fuel as a percentage left rather than gallons.

Having your method access and change data within another object (see if you can move the method to within the other object, where hopefully it will make more sense)

Scope

Spend time thinking about anything that is not private, is there a way you could increase encapsulation by reducing the amount of data shared. Is your publicly accessible interface clean and free of clues as to how the object is implemented.

Also be wary of protected members, it can seem natural for inherited objects to have access to data but this can lead to problems refactoring later. Loose coupling between inheritance trees is hard to achieve but important to consider.

Benefits of encapsulation

• Increase cohesion (Relation of data/methods within a class, high cohesion is good!)
• Decrease coupling (High coupling of classes can make them hard to reuse, replace and test)
• Better separation of concerns (when classes are highly cohesive a class is more likely to only focus upon itself)
• Easier to reuse (A loosely coupled class will be easier to reuse in other places)
• Easer to make changes (Only changes to the public interface require changes in other places)
• Reduces complexity (By only requiring you to think about one class at a time)

Disadvantages of encapsulation

• Can require more code (Boiler plate, getters/setters etc.)

Inheritance and encapsulation

Inheritance can be seen to be breaking encapsulation as you are exposing the workings of the class to the class that is sub classing. Over use of inheritance where it is not required will often lead to the breaking of encapsulation. So we should favor composition (Containing another object) over inheritance as a mechanism for code reuse. 

Generic Fun : Generic Implicit Operators

Just playing around with generics, thinking about using them for things like lazy loading wrappers and potentially for dirty tracking and things like that. Lets start with a simple generic wrapper that doesn't do anything.

 public class Wrapper<T>  
 {  
     public T Value { get; }  
   
     public Wrapper(T value)  
     {  
         Value = value;  
     }  
 }  

(Using C# 6)

One of the problems is that you always have to add in a .Value for reading out and new Wrapper<T>(someData) for creating. One solution to this is to use implicit operators. Thus allowing you to create by just assigning a instance of T to the variable, and read out by assigning in to a T variable.

 public class Wrapper<T>  
 {  
     private T _value;  
   
     public Wrapper(T value)  
     {  
         _value = value;  
     }  
   
     public static implicit operator Wrapper<T>(T value)  
     {  
         return new Wrapper<T>(value);  
     }  
   
     public static implicit operator T(Wrapper<T> value)  
     {  
         return value._value;  
     }  
 }  

This will allow you to do things like this:

 Wrapper<string> textWrapper = "Text";  
 string text = textWrapper;  
   
 Wrapper<int> numberWrapper = 23;  
 int number = numberWrapper;  

There are some drawbacks to this, as if you are reading in to implicitly typed local variables (var), it would treat it as a Wrapper<T> unless you specify the type of the variable. Causing the properties of T not to be available without accessing the value of the wrapper putting in another variable.

It could be useful to help reduce the amount of code you need to write when using a generic wrapper, I was thinking maybe this could be used for lazy loading?

 public class LazyLoaded<T>  
 {  
     private T _value;  
     private bool _loaded;  
   
     public LazyLoaded(T value)  
     {  
         _value = value;  
     }  
   
     public T Value()  
     {  
         if (!_loaded)  
         {  
             // Load data  
             _loaded = true;  
         }  
   
         return _value;  
     }  
   
     public static implicit operator LazyLoaded<T>(T value)  
     {  
         return new LazyLoaded<T>(value);  
     }  
   
     public static implicit operator T(LazyLoaded<T> value)  
     {  
         return value._value;  
     }  
 }  

Even if it's not useful, still interesting :)

Autofac

Basic Setup

Autofac is a nifty dependency injection container that comes as a PCL (Portable Class Library) so it can be used in Xamarin projects.

To set it up you need to build a container using the ContainerBuilder class:

 var containerBuilder = new ContainerBuilder();  
   
 containerBuilder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());  
 
 // Register Types
   
 _container = containerBuilder.Build();  

You can then register types like this:

 container.RegisterType<First>().As<IFirst>();   

To use the container to resolve objects you need to get a lifetime scope from it:

 using (var scope = _container.BeginLifetimeScope())  
 {  
   // Reslove Types  
 }  

You can then resolve types like so:

 var first = scope.Resolve<IFirst>();  

If you are using MVC/Web.Api you can add additional nuget packages that will enable constructor injection on your controllers!

Automatic resolution of concrete types

If you want the container to automatically resolve concrete types you can add this to the container builder. This will mean that if it can't find a registration and the type is a concrete (non-interface, non-abstract) class it will just new up the class and return it.

 containerBuilder.RegisterSource(new AnyConcreteTypeNotAlreadyRegisteredSource());  

Passing some parameters

You can pass in some parameters and the container will automatically resolve the non passed ones. This means you can have a constructor like this and still pass in some of the parameters and have the container resolve the others automatically.

 public Test(IFirst first, ISecond second)  

To pass in the IFirst parameter just do:

 var test = scope.Resolve<Test>(new TypedParameter(typeof(IFirst), first));  

This will then pass first in and create a new Second instance. 

delegate Factories

You can use a Func<T> as a factory, this will then pass in a function that will resolve instances from the container so you can create multiple instances.

     public NeedAFactory(Func<Test> factory)  
     {  
       _test1 = factory();  
       _test2 = factory();  
     }  

Delegate Factories with parameters

You can also add a Func that takes parameters and this will be passed in to the constructor of the class when it is constructed.

   internal class Parent  
   {  
     private IChild _child;  
   
     public Parent(Func<Parent, IChild> factory)  
     {  
       _child = factory(this);  
     }  
   }  
   
   internal class Child : IChild  
   {  
     private readonly Parent _parent;  
   
     public Child(Parent parent)  
     {  
       _parent = parent;  
     }  
   }  

When autofac creates the child class it will pass the varable specified in the parent (this).

C# 6 (Part 2)

String Interpolation

String interpolation is a replacement/alternative to string.format.

 var name = "Rob";  
 var output = "Hello \{name}";  
   
 Console.WriteLine(output);  

This will output "Hello Rob"

This is quite a nice feature as I find the syntax a lot easier to read than string.format.

Resharper 9.1 does not support this yet and will highlight it as an error, but it still compiles and runs.

https://roslyn.codeplex.com/discussions/540869
https://roslyn.codeplex.com/discussions/570614

nameof Operator

Quick and easy way of getting the name of something

 Console.WriteLine(nameof(test));  // varable outputs: "test"
 Console.WriteLine(nameof(TestProperty));  // property outputs: "TestProperty"
 Console.WriteLine(nameof(MyClass.TestProperty));  // property of class outputs: "TestProperty"
 Console.WriteLine(nameof(System.Text));   // namespace outputs: "Text"
 Console.WriteLine(nameof(MyClass.Method));  // method outputs: "Method"

Another useful little feature for when you are setting things using reflection and don't want to use strings, you can use an expression tree but this is simpler and I assume more efficient.

Resharper 9.1 does not support yet but it still compiles and runs
https://roslyn.codeplex.com/discussions/570551

Expression Bodied Members

You can now define fields with lambda expressions.

 private int _total => _first + _second;  
 private static Program CreateProgram => new Program();  

Can also be used to define methods.

 public int Add(int x) => _number += x;  

Nice little feature for quick definition of simple methods.

Exception Filters
It is now possible to filter exceptions without affecting the stack trace.

 try  
 {  
   ThrowException();  
 }  
 catch (Exception e) if (e is InvalidDataException || e is InvalidOperationException)  
 {  
   // Handle it  
 }  

This can also be used (abused) to log exceptions.

 try  
 {  
   ThrowException();  
 }  
 catch (Exception e) if (Log(e))  
 {  
   // Handle it  
 }  

This seems to be an acceptable abuse of the feature as it is described in the language spec :)

Asp.net Mvc Image Helpers (Part 3)

Image helper with lazy loading

This article looks at creating a html helper to lazy load images using the jQuery lazy load plugin.

It follows on from 2 earlier articles on creating html helpers for image loading:

Asp.net Mvc Image Helpers (Part 1)

Asp.net Mvc Image Helpers (Part 2)

There are a few different ways of making an image lazy load, but this seems to be the simplest to get working I've found so far.

First of all you need to install the Lazy load plugin for jQuery (search "lazyload") using the Nuget package manager. There are 2 versions available, I used 1.8.4. You will also need some additional images for this part, a ajax style loading spinner (create your own here!) and a 1x1 pixel spacer image (create one or download from here).

First we will create the html helper that will generate the html code that lazy loads the image.

 public static MvcHtmlString LazyLoadImage(  
               this HtmlHelper helper,  
               string image,  
               string alternative,  
               int width,  
               int height)  
 {  
   var urlHelper = new UrlHelper(helper.ViewContext.RequestContext);  
   var url = urlHelper.Action("ImageResize", "Image", new { image, width, height });  
   var spaceUrl = urlHelper.Action("Image", "Image", new { image = "spacer.gif" });  
   
   var html = String.Format("<div class='lazyWrapper' style='height:{0}px; width:{1}px'>", height, width);  
   html += String.Format("<img class='lazy' src='{0}' data-original='{1}' alt='{2}'/>", spaceUrl, url,  
               alternative);  
   html += String.Format("</div>");  
   
   return MvcHtmlString.Create(html);  
 }  

It uses the Image Controller re-size method created in part 2 of this series.

We create a div element to wrap the img element, this enables us to set the background of the div to the loading spinner element and easily center the spinner. We set the img tags src attribute to a single pixel transparent image so that it will not show until updated by jQuery lazy load. The data-original tag holds the image that we want to lazy load.

Done!