Java vs C# – Part 1

Disclaimer: long post!

Introduction

While some of my friends and colleagues seem to think that I don’t like Java and that I am some sort of Microsoft/.NET zealot, that is actually not true! Smile with tongue out I do like Java, and I worked with it several years.

There are several articles out there on the differences and similarities between C# and Java, but none actually satisfied me. In this new series of posts, I will try to explain these similarities and differences, as extensively and accurately as I can. I don’t want to start a religious war, but I won’t refrain from emitting judgments on what I think is best in each. I will try to cover as much as I can, but I won’t drill into APIs, instead will focus on each language’s intrinsic characteristics.

This first post will focus on high-level constructs, what I call structure: namespaces and types. I will be covering Java 8 and C# 5, the latest (as of February 2015) versions of these languages.

Update: See the second post here.

Similarities

Both languages (Java and C#) are case-sensitive, strictly object oriented, offering classes, enumerations and interfaces, single inheritance model and all of the types live in namespaces/packages. Also, all support attributes/annotations, methods and fields, including static ones. The base class for all types, in both cases, is called Object. Both have the same basic operators, comparable base types and exception handling mechanisms. Both start executing by a static method called main/Main.

Compiled Units

A Java class compiles to an identically-named class file; these files exist on their own, but are usually stored together inside a jar, war or ear, which are basically ZIP files with a manifest file attached to, for better manageability. These files, of course, can contain other resources, such as images or text files.

C# classes always exist in binary assemblies, which can have two basic forms (extensions):

  • dll: a library, does not run on its own;
  • exe: a stand-alone executable, which can either be a Console or a Windows Forms / Windows Presentation Foundation graphical application.

Assemblies can also include metadata and embedded resources, of any type. C#/.NET actually defines another compilation unit, the module, but typically a module matches an assembly, although it is possible to have it other way, for more advanced scenarios.

Namespaces

Both in Java and in C# we have the notion of namespaces or packages, which can be nested. In C#, the namespace declaration must wrap all of its types, and therefore we can have several namespace declarations in a source file, even nested:

namespace MyNamespace1

{

    public class Class1

    {

    }

}


namespace MyNamespace2

{

    public class Class2

    {

    }


    namespace MyNamespace3

    {

        public class Class3

        {

        }

    }

}

In Java, the package declaration goes on the top of a source file, meaning, it can only contain a single package:

package myPackage;


public class MyClass

{

}

There is one important difference between Java and C#: in Java, the namespace must be identical to the physical folder structure, that is, a class belonging to the a.b package must be physically located in an a\b folder; Java won’t compile it otherwise. The generated .class file must be located in the same folder, such as a\b\MyClass.class.

Java and C# can simplify accessing classes in other namespaces/packages by importing these, like we see here for Java, where we can import all types (*), or a type at a time:

//import java.lang.*;    automatically imported

import java.io.*;

import java.lang.reflect.Array;

Java imports automatically the types in the java.lang package, C# does not automatically import any namespace, and it doesn’t allow importing a single type:

using System;

using System.IO;

But it also lets us define type aliases per source file using the same syntax:

using date = System.DateTime;


public class MyClass

{

    public date GetCurrentDate()

    {

        //...

    }

}

Top Level Elements (Types)

Java and C# offer a very close syntax, in some cases, if we discount the different language conventions, it’s really hard to tell one from the other, but there are some important differences.

Java offers the following top level elements, besides packages:

  • Classes (including generic);
  • Interfaces (including generic);
  • Enumerations.

And C# the same plus some more:

  • Classes (including generic);
  • Interfaces (including generic);
  • Enumerations;
  • Structures;
  • Delegates (including generic).

Basic Types

The basic types in the two languages (C#/Java) are:

  • Object/Object (C# shorthand: object);
  • String/String (C# shorthand: string);
  • Byte/byte (C# shorthand: byte);
  • SByte/N/A (C# shorthand: sbyte);
  • Boolean/boolean (C# shorthand: bool);
  • Char/char (C# shorthand: char);
  • Int16/short (C# shorthand: short);
  • UInt16/N/A (C# shorthand: uint);
  • Int32/int (C# shorthand: int);
  • UInt32/N/A (C# shorthand: uint);
  • Int64/long (C# shorthand: long);
  • UInt64/N/A (C# shorthand: ulong);
  • Single/float (C# shorthand: float);
  • Double/double (C# shorthand: double);
  • Decimal/N/A (C# shorthand: decimal);
  • dynamic/N/A;
  • Arrays.

As you can see, C# offers unsigned and signed versions of all integer types and also a high-precision Decimal type. It also as a dynamic type, used for late-binding (runtime) operations without strong compile-time checks.

C# offers three kinds of arrays:

  • Single dimension: int [] numbers;
  • Multi dimension: int [,] matrix;
  • Arrays of arrays, also called, jagged arrays: int [][] matrix;

Java also has single dimension and jagged arrays, but no multi dimension ones.

C# lets us use the var keyword for declaring a variable and automatically initializing it. This is a shorthand for the initialization’s type:

var i = 10;            //int

var s = "string";      //string

var f = SomeMethod();  //method's return type, except void

In C# as in Java, we can specify suffixes for clarifying the desired type of a literal:

  • 10n: integer;
  • 10l: long;
  • 10f: float;
  • 10d: double;
  • 10u: unsigned int (C# only);
  • 10ul: unsigned long (C# only);
  • 10m: decimal (C# only).

Both lowercase or uppercase letters are allowed as the suffix.

Classes

Classes in Java and C# are allocated in the heap. A class can inherit from a single base class, if not specified, it will inherit from Object. It can implement any number of interfaces.

Structures

C# has a unified type system, meaning, primitive types (integers, floating points, booleans, etc) coexist in the same type hierarchy as composite classes. This is different in Java, where, for example, the int and Integer types are not related, even if it is possible to convert between the two. All primitive types in C# are structures, not classes, which means they are allocated in the stack instead of the heap. In Java this also occurs for primitive types, but there is no notion of explicit structures, and we can’t build our own types to be stored in the stack. A structure in C# cannot inherit from any class explicitly, but it can implement any number of interfaces, and also cannot declare a destructor/finalizer:

public struct MyStructure : IMyInterface

{

    public void MyMethod()

    {

    }

}

Structures and enumerations in C# are called value types and classes and interfaces are called reference types. Because of C#’s unified type system, a structure always implicitly inherits from System.ValueType.

Interfaces

In C#, an interface can only have:

  • Instance method declarations;
  • Instance property declarations;
  • Instance event declarations.

It can be generic or non-generic. Both classes and structures can implement interfaces. An interface can always be assigned null, it is a reference type. Also, a generic interface in C# can be made covariant or contravariant.

In Java, things are a bit different, since they can have also have statics and (the horror!), method implementations:

  • Instance method declarations;
  • Fields (always implicitly static) with a value (constants);
  • Default methods: methods with default implementations.

They can also be generic or otherwise, and can be implemented by enumerations. In Java, an interface’s members can also have visibility levels defined, that is, they are not always public.

If a Java interface only has one method, or, at least, one non-default method (more on this later), it can be marked as a functional interface, in which case, it can be used in lambda functions, the method is implicitly called (see an example below in the Delegates section).

Generic Types

Generics are quite different, internally, in Java and C#. Both languages support generic classes and interfaces, but in C# they are a first-class construct, with reflection support, but in Java they cease to exist once a generic class is compiled. That is, in Java, a List<String>, at runtime, becomes just List, the generic parameter String is erased, this is in order to ensure backward compatibility with prior Java versions that didn’t have generics. This doesn’t happen in C#, and we can at runtime reflect on a generic class and its parameters.

Both languages support any number of generic parameters and constraints on them. In C# these constraints are:

  • Base class, structure or interface: forces the generic parameter to inherit or implement from a specific class, structure or interface;
  • Public non-abstract class with a public parameterless constructor: only allows generic parameters that are non-abstract (or interfaces) and have a public constructor that doesn’t take parameters;
  • Reference or value type: a generic parameter either has to be a reference (class or interface) or a value type (structure or enumeration), as specified.

An example:

public class GenericClassWithReferenceParameter<T> where T : class

{

}


public class GenericClassWithValueParameter<T> where T : struct

{

}


public class GenericClassWithMyClassParameter<T> where T : MyClass

{

}


public class GenericClassWithPublicParameterlessParameter<T> where T : new()

{

}


public class GenericClassWithRelatedParameters<K, V> where K : V

{

}


public class GenericClassWithManyConstraints<T> where T : IDisposable where T : new() where T : class

{

}

Java accepts the following constraints:

  • Base class: a generic parameter must inherit from a base class;
  • Implementing interface: a generic parameter must implement some interface;
  • Unbounded generic type: a generic parameter must inherit/implement some generic type.

Some examples:

public class GenericClassWithBaseClassParameter<T extends BaseClass>

{

}


public class GenericClassWithInterfaceParameter<T extends Interface>

{

}


public class GenericClassWithBaseMatchingParameter<T, ? super T>

{

}


public class GenericClassWithManyInterfaceParameters<T implements BaseInterface1 & BaseInterface2>

{

}


In Java, we can specify a generic of an unknown type:

MyInterface<?> var;

Java also has some terrible limitations:

  • There cannot be generics of primitive types, for example, MyGenericClass<int>, only of non-primitives, like MyGenericClass<Integer>;
  • There cannot be generic arrays.

Because C# supports any kinds of generic parameters, if we want to initialize explicitly some variable of a generic parameter type, we need to use the default keyword:

public class MyGenericClass<T>

{

    public void MyMethod()

    {

        T someField = default(T);

    }

}

Finally, the base class of some class inheriting from a generic type is not that generic type, but its base class, which can seem awkward. This happens in C# and in Java.

Delegates

A delegate in C# is a method signature, composed of:

  • A name;
  • A return type;
  • Parameters (number and type).

Delegates are the building blocks of events. A delegate can either point to a static, an instance or an anonymous method (lambda), provided the signature is the same:

public delegate double Operation(double v1, double v2);


//a delegate pointing to a static method

Operation addition = Operations.Add;


//a delegate pointing to an instance method

Operation subtraction = this.Subtract


//a delegate pointing to an anonymous method using lambdas

Operation subtraction = (a, b) =>

{

    return a + b;

};

A delegate can be generic:

public delegate void Action<T>(T item);

Delegates inherit automatically from System.Delegate, because of this, they have built-in support for dynamic and asynchronous invocation.

Java has a similar construct, functional interfaces. These are interfaces with a single non-default method, which can be used in lambda functions:

public interface MyWorkerFunction

{

    @FunctionalInterface

    public void doSomeWork();

}


public void startThread(MyWorkerFunction fun)

{

    fun.doSomeWork();

}


public void someMethod()

{

    startThread(() -> System.out.println("Running..."));

}

If an interface is marked as functional but has more than one method, it will not compile.

Enumerations

Enumerations in Java can have members (constructors, fields and methods) and even implement interfaces, something that is not possible in C#:

public enum MyEnumeration implements MyInterface

{

    A_VALUE(1),

    ANOTHER_VALUE(2);


    private int value;


    private MyEnumeration(int value)

    {

        this.value = value;

    }


    public static String fromInt(int value)

    {

        if (value == A_VALUE.value) return ("A_VALUE");

        else return ("ANOTHER_VALUE");

    }

}

In C#, no methods or interfaces, but we can have an enumeration be implemented based on a primitive integer type, including unsigned (the default is signed int):

public enum MyEnumeration : uint

{

    AValue = 1,

    AnotherValue = 2

}

Implicitly, all C# enumerations inherit from System.Enum.

In both cases, C# and Java, we can specify integral values for each enumeration member, and, if we don’t, members will get sequential values.

Type Visibilities

A type in Java has four possible visibilities:

  • package: only accessible by other classes in the same package (the default);
  • public: accessible by everyone.

And C# types have similar ones, plus one:

  • internal: only accessible by other classes in the same assembly (the default);
  • public: accessible by everyone.

Inheritance

In C#, the syntax for extending a class and for implementing an interface is exactly the same:

public class MyClass : BaseClass, IInterface

{

}

Whereas in Java there are the extends and the implements keywords, respectively, for classes and interfaces:

public class MyClass extends BaseClass implements Interface

{

}


public interface DerivedInterface extends BaseInterface1, BaseInterface2

{

}

Both can inherit from a single class and implement as many interfaces as desired. Also, an interface can itself inherit from several interfaces.

In C# it is possible to implement interfaces in one of two ways:

  • implicit: where the interface’s members are directly accessed through the implementing class;
  • explicit: where we have to cast the class to the explicitly implemented interface before we can use it; this is useful, among other reasons, if we want to implement several interfaces which offer identically-named members.

Let’s see how they look in C#, in this example, interface IMyInterface1 is explicitly and IMyInterface2 implicitly implemented:

public class MyClass : IMyInterface1, IMyInterface2

{

    void IMyInterface1.MyMethod1()

    {

    }


    public void MyMethod2()

    {

    }

}

Explicitly-implemented members are always private and cannot be virtual or abstract. If we want to call a method or access a property of an explicitly implemented interface, we need to cast the instance first:

MyClass c = new MyClass();

IMyInterface1 i = (IMyInterface1) c;

i.MyMethod();

Java only has implicit interface implementations:

public class MyClass implements MyInterface

{

    public void myMethod()

    {

    }

}

Inner Classes

In Java as in C#, we can have multiple levels of nested/inner classes, structures and interfaces, but in Java they can be static or instance:

public class MyClass

{

    public static class MyStaticInnerClass

    {

    }


    public class MyInnerClass

    {

    }

}

Instance inner classes can only be instantiated when we have an instance of its containing class (do notice the awful syntax):

MyClass.MyStaticInnerClass c1 = new MyClass.MyStaticInnerClass();


MyClass c2 = new MyClass();


MyClass.MyInnerClass c3 = c2.new MyInnerClass();

In C#, any inner class can be instantiated, with or without an instance of the containing class, provided its visibility level is respected:

public class MyClass

{

    public class MyInnerClass

    {

    }

}


MyClass.MyInnerClass c = new MyClass.MyInnerClass();

For C# the following visibility levels exist:

  • internal: only accessible by other classes in the same assembly (the default);
  • protected: only accessible by descending classes;
  • protected internal: derived classes or classes from the same assembly;
  • private: only accessible by the declaring class;
  • public: accessible by everyone.

Whereas for Java:

  • package: only accessible by other classes in the same package (the default);
  • protected: only accessible by descending classes;
  • private: only accessible by the declaring class;
  • public: accessible by everyone.

Abstract Classes

In Java as in C# we have abstract classes, and the syntax is exactly the same:

public abstract class MyClass

{

    public abstract void myMethod();

}

C# structures cannot be abstract.

Sealed Classes

Both frameworks allow a class to be marked as sealed/final, meaning, it cannot be inherited from:

public sealed class MyClass

{

    //a C# sealed class

}

public final class MyClass

{

    //a Java final class

}

C# structures are always implicitly sealed.

Static Classes

In C# we can have static classes, which are roughly equivalent to being at the same time abstract and sealed. Static classes only allow static members (properties, methods, fields and events):

public static class MyClass

{

    public static void MyMethod()

    {

    }


    public static string MyField;


    public static int MyProperty { get; set; }


    public static event EventHandler MyEvent;

}

Java does not have the concept of static classes.

Nullable Types

Because it is allocated in the stack, a variable of a structure or enumeration type always has a value, so, it cannot be null, but we can use a handy syntax to turn it into a nullable type, which can itself be made null:

int ? nullableInteger = null;

nullableInteger = 1;


if (nullableInteger.HasValue)    //if (nullableInteger != null)

{

    int integer = nullableInteger.Value;    //int integer = nullableInteger

}

In Java, primitive values can never be null, we need to resort to their corresponding wrapper classes:

Integer nullableInteger = null;

nullableInteger = new Integer(1);

Classes and interfaces in C# (reference types) are always nullable, meaning, can always be assigned null.

Partial Classes

C# allows marking a class as partial, meaning, its contents may spread through several different source files; the actual compile-time class will be built from all of these files. This is very useful when we have automatically generated files that we don’t want to change, but rather complement:

//in file MyClass.Generated.cs

public partial class MyClass

{

    public void OneMethod()

    {

    }

}


//in file MyClass.cs

public partial class MyClass

{

    public void AnotherMethod()

    {

    }

}

Anonymous Classes

Java has anonymous classes: we can create anonymous classes that implement some interface or extend some class, by implementing all of its abstract methods:

this.addEventListener(new ListenerInterface

{

    public void onEvent(Object source, Event arg)

    {

    }

});

Anonymous classes in C# do not contain explicitly defined methods, only read-only properties; two anonymous classes are considered of the same type if their members are declared in the same order and with the same types:

var i1 = new { A = 10, B = "" };

var i2 = new { A = 1000, B = "string" };


//these two classes have the same type

i1 = i2;

In order to support anonymous classes, C# introduced the var keyword, which allows us to have a variable infer its type automatically. An anonymous type is created when a variable is created without a static type.

Type Members

In .NET we have the following type members:

  • Constructors (static and instance);
  • Destructors;
  • Methods (static and instance);
  • Fields (static and instance);
  • Properties (static and instance);
  • Events (static and instance);
  • Overridden operators and type conversions (discussed on the next post).

Java only has:

  • Constructors (static and instance);
  • Constructor blocks;
  • Destructors;
  • Methods (static and instance);
  • Fields (static and instance).

Static Constructors

Static constructors or class initializers are basically the same in C# and Java, but have a slightly different syntax, here is the Java one:

public class MyClass

{

    static

    {

        //do something the first time the class is used

    }

}

And the C# syntax:

public class MyClass

{

    static MyClass()

    {

        //do something the first time the class is used

    }

}

Java offers another weird thing: constructor blocks. You can have any number of them, and their code will be included automatically into all of the class’ constructors:

public class MyClass

{

    {

        System.out.println("First constructor block, called before constructor");

    }


    public MyClass()

    {

        System.out.println("MyClass()");

    }


    {

        System.out.println("Second constructor block, called before constructor but after first constructor block");

    }

}

Destructors

In C# a destructor, or finalizer, is just a shorthand syntax to the Finalize method. This method is called by the Garbage Collector when an instance is about to be freed. Java has an identical method, called finalize, which serves a similar purpose. Strictly speaking, none of these methods is actually a destructor, but they are sometimes called that.

In C#, we can use the C++ syntax instead of overriding Finalize:

public class MyClass

{

    ~MyClass()

    {

        //object is being freed

    }

}

Static Members

Unlike C#, Java allows referencing static members through an instance variable, for example:

public class MyClass

{

    public static void doSomething()

    {

    }

}


MyClass c = new MyClass();

c.doSomething();

Properties

Properties are a useful C# construct, which allows a cleaner syntax to changing fields:

public class MyClass

{

    public int MyProperty { get; set; }

}


MyClass c = new MyClass();

c.MyProperty++;

We can have auto-implemented properties (such as in this example) or properties with an explicit backing field:

public class MyClass

{

    private int myField;


    public int MyProperty

    {

        get

        {

            return this.myField;

        }

        set

        {

            this.myField = value;

        }

    }

}

The Java equivalent can only be achieved with methods:

public class MyClass

{

    private int myProperty;


    public void setMyProperty(int value) { this.myProperty = value; }

    public int getMyProperty() { return this.myProperty; }

}


MyClass c = new MyClass();

c.setMyProperty(c.getMyProperty() + 1);

In C# we can also define indexed properties for classes, interfaces and structures, like in this example using an integer index:

public class MyCollection

{

    private Object [] list = new Object[100];


    public Object this[int index]

    {

        get

        {

            return this.list[index];

        }

        set

        {

            this.list[index] = value;

        }

    }

}

We are not limited to integer indexes, any type can be used as the key to an indexed property.

Finally, properties can have different visibility levels for the getter and setter methods, and can even have just one of them (usually just a setter does not make much sense):

public int InternalProperty

{

    get;

    private set;

}


public string GetOnlyProperty

{

    get

    {

        return this.InternalProperty.ToString();

    }

}

Events

Events are C#’s implementation of the Publisher/Subscriber and Observer Patterns: it allows to register methods that will be called when the event is raised, and offers a simple syntax for registering, unregistering and clearing event handlers. An event handler is just an instance of a delegate, the delegate is the event’s signature:

public class MyClass

{

    public event EventHandler MyEvent;


    public void ClearEventHandlers()

    {

        //check for registered event handlers

        if (this.MyEvent != null)

        {

            //raise event

            this.MyEvent(this, EventArgs.Empty);


            //clear event handlers

            this.MyEvent = null;

        }

    }

}


MyClass a = new MyClass();


//register event handler

c.MyEvent += OnMyEvent;


//unregister event handler

c.MyEvent -= OnMyEvent;

Like with properties, it is also possible in C# to implement the event add and remove methods explicitly, so as to add our own behavior:

public class MyClass

{

    private EventHandler myEvent;


    public event EventHandler MyEvent

    {

        add

        {

            this.myEvent += value;

        }

        remove

        {

            this.myEvent -= value;

        }

    }

}

Automatic Initialization of Fields and Properties

All fields declared in a class are initialized to their type’s default value (0 for integers and floating point number, false for booleans, null for classes). C#’s auto-implemented properties are also implicitly initialized to their type’s default value. This behavior is the same in both languages, of course, Java does not have properties.

Member Visibilities

C# has four visibility levels for members:

  • private: accessible from the declaring type;
  • internal: accessible from types in the same assembly as the declaring type;
  • protected: accessible from types inheriting from the declaring type;
  • protected internal: accessible from types either inheriting from the declaring type or from its same assembly;
  • public: accessible by everyone.

And Java, we only have:

  • package: only accessible by classes in the same package;
  • protected: only accessible by descending classes;
  • private: only accessible by the declaring class;
  • public: accessible by everyone.

Virtual Members

In Java, all methods are virtual by default (there is no virtual keyword), unless marked as final.

In C#, a method, property or event needs to be explicitly marked as virtual so that it can be overridden, and all overrides must state so:

public class MyBaseClass

{

    public virtual void MyMethod()

    {

    }

}


public class MyDerivedClass : MyBaseClass

{

    public override void MyMethod()

    {

    }

}

If a derived class member with the same name as one in the base class exists, but it is not an override of it, we need to mark it as new:

public class MyBaseClass

{

    public void MyMethod()

    {

    }

}


public class MyDerivedClass : MyBaseClass

{

    public new void MyMethod()

    {

        //no relation with MyBaseClass.MyMethod

    }

}

Sealed Members

In C# as in Java, it is possible to mark a member (method) as sealed/final, meaning, it is not available for overriding in a derived class. In C# the same applies to events and properties, which, of course, don’t exist in Java.

C# syntax:

public class MyClass

{

    public sealed void DoSomething()

    {

    }

}

And Java syntax:

public class MyClass

{

    public final void doSomething()

    {

    }

}

Abstract Members

In both languages, abstract members (methods) can exist in abstract classes, but they are not required: we can have abstract classes without any abstract members. In C#, besides methods, we can also have abstract properties and events.

Generic Methods

Methods can also be generic, regardless of living in generic classes or not. The same constraints apply, but generic methods also have automatic type inference:

public class MyClass

{

    public static int Compare<T>(T v1, T v2)

    {

        if (v1 == v2)

        {

            return 0;

        }


        return -1;

    }

}


//no need to specify the int parameter type

int areEqual = MyClass.Compare(1, 2);

Read-only and Constant Fields

Both Java and C# have read-only fields, but C# uses the readonly keyword:

public static class Singleton

{

    //a C# readonly field

    public static readonly Singleton Instance = new Singleton();

}

And Java uses final:

public class Singleton

{

    //a Java final field

    public static final Singleton INSTANCE = new Singleton();

}

C# also offers another kind of read-only field, constants. A constant is always static and can only be of one of the primitive types, or an enumerated value:

public static class Maths

{

    //a C# constant field

    public const double PI = 3.1415;

}

The difference between readonly and const is that the C# compiler inlines all constants, that is, it actually replaces any references to it by their concrete values. The Java compiler does something similar for static final fields. Read-only fields can be initialized inline, together with the field declaration, or in constructors (static or instance).

Technical Review

I couldn’t have written this post without the technical review by my friend and colleague Roberto Cortez (@radcortez), of Java fame. Thanks, Roberto! Winking smile

Next Steps

That’s it for now. Stay tuned for the next post, where I will talk about other language differences. Let me hear from you!

Lesser-Known NHibernate Features: Versioning and Optimistic Concurrency

NHibernate supports the notion of entity version. An entity version is the value of some entity property that is mapped as versioned. There are several strategies for versioning:

  • A numeric counter;
  • The current (UTC) timestamp;
  • The database timestamp;
  • The system elapsed ticks (DateTime.Ticks);
  • A database-specific row version (ROWVERSION in SQL Server, ORA_ROWSCN in Oracle, etc).

 

We map a version property as this:

public class VersionedEntity

{

    public int Id { get; protected set; }

    public int Version { get; protected set; }

}


public class VersionedEntityClassMapping<VersionedEntity>

{

    public VersionedEntityClassMapping()

    {

        this.Id(x => x.Id, x => x.Generator(Generators.Identity));

        this.Version(x => x.Version, x => x.Type(NHibernateUtil.Int32));

        //etc

    }

}

If you wish to use a strategy other than auto-incrementing versioning, just replace NHibernateUtil.Int32 by another instance of a class implementing IVersionType, such as NHibernateUtil.Ticks, NHibernateUtil.Timestamp, NHibernateUtil.UtcDateTime, NHibernateUtil.DbTimestamp, NHibernateUtil.Binary (for SQL Server), or a similar one – or roll out your own strategy.

Close to the notion of versioning comes optimistic concurrency. Using optimistic concurrency control, when a record is about to be updated, it is checked against a pre-saved value or set of values (the version), together with its primary key. If it doesn’t match, the number of affected records will be 0 instead of 1, and we know something went wrong: because the primary key doesn’t change, then it has to be the version:

UPDATE some_table

SET some_column = @p1

WHERE id = @p2

AND version = @p3

Optimistic concurrency can use:

  • The version property (if any);
  • All of the entity’s properties;
  • All the dirty properties.

We just need to tell NHibernate which strategy we want to use:

public class VersionedEntityClassMapping<VersionedEntity>

{

    public VersionedEntityClassMapping()

    {

        this.Id(x => x.Id, x => x.Generator(Generators.Identity));

        this.Version(x => x.Version, x => x.Type(NHibernateUtil.Int32));

        this.OptimisticLock(OptimisticLockMode.Version);//NHibernate 4.0, no need to specify since this is the default

        //etc

    }

}

And that’s it. Happy versioning!

Learning Microsoft Azure Review

Introduction

I was recently asked by Packt Publishing to do a review of their title Learning Microsoft Azure, and so I did.

It wasn’t the first time I did a review on an Azure book, I also reviewed Microsoft Azure Development Cookbook, Second Edition, and you can see my review here.

This time, it is an introductory book, where the reader is introduced to Microsoft Azure, and guided as he/she develops a full solution for an imaginary industrial bakery, from end to end, including a mobile app. It covers technologies such as ASP.NET MVC 5, Windows Phone 8, Entity Framework Code First and Web API, always using C# and .NET as the backing framework. At the end of each chapter, there’s a questions and answers page where we can assess our level of understanding of the topics that were discussed in it.

The author is Geoff Webber-Cross (@webbercross), which also authored another book on Azure and Windows Phone.

Chapter 1: Getting Started with Microsoft Azure

The first chapter, as we might expect, does an introduction to cloud computing and the Microsoft Azure service, presents a decision framework for aiding in selecting a cloud service as opposed to on-premises, guides the reader in creating an Azure account including it’s many services and costs, and lists the most relevant terms that we will be encountering throughout the book.

Chapter 2: Designing a System for Microsoft Azure

Here we are presented with the sample scenario, its objectives and requirements and the architectural vision of it. Different views on the system and its subsystems are presented and for each the technical decisions are explained.

Chapter 3: Starting to Develop with Microsoft Azure

Next we setup the development environment, choose a Visual Studio edition, download the required SDK and create a project to be published in our Azure account. Visual Studio Online is also presented and it’s integration with Azure, namely, in order to ensure continuous integration and delivery.

Chapter 4: Creating and Managing a Windows Azure SQL Server Database

Here we get an overview of the SQL functionality of Azure, how to create and manage databases using the portal, Visual Studio and the SQL Server Management Studio, then we learn how to use Entity Framework Code First to access and manipulate its data, and to migrate to and from different versions using the Migrations API.

Chapter 5: Building Azure MVC Websites

This chapter explains how we can build an MVC application using OAuth authentication (social accounts such as Twitter, Facebook, Google and Microsoft Live). It goes on explaining how we can set up custom domains and SSL certificates for HTTPS and how to integrate the Azure Active Directory for single sign-on and custom permissions.

Chapter 6: Azure Website Diagnostics and Debugging

This one is about diagnosing problems and debugging our applications. It presents the basic built-in tracing and logging features of Azure and how we can obtain this information and goes on to show how we can use table storage and blobs for custom storing of structured logs and its querying. Kudu is briefly introduced and at the end we learn how to do remote debugging.

Chapter 7: Azure Service Bus Topic Integration

Next up is Service Bus, Azure’s enterprise service bus service. We learn how to configure it, create and manage topics using the portal and how to use the service from our MVC application and expose it as a service.

Chapter 8: Building Worker Roles

The next chapter is about Worker Roles, a feature of Azure Websites that performs disconnected (non web-related) tasks. The reader is guided in creating a Worker Role with Visual Studio, executing it in the Emulator and publishing it to Azure. The example presented builds on the Service Bus topics discussed in the previous chapter. We also learn about other scheduling mechanism of Azure, Scheduler jobs, and implement an example using Queues.

Chapter 9: Cloud Service Diagnostics, Debugging, and Configuration

Here we learn about configuring and using the diagnostics features of Cloud Services, again expanding the concepts introduced in chapter 6. We talk about IntelliTrace and Remote Debugging and on how to connect to our virtual machines with Remote Desktop. Finally we are given an example on how to use script tasks to automate common needs.

Chapter 10: Web API and Client Integration

This chapter introduces ASP.NET Web API, Microsoft’s latest technology for building REST web services and SignalR, for asynchronous, duplex, real-time communication between web clients and the server. The provided example shows how to integrate these two technologies to broadcast messages to connected clients, including a desktop Windows Presentation Framework (WPF) application. In the end we learn how to use the Active Directory to authorize accesses to our services.

Chapter 11: Integrating a Mobile Application Using Mobile Services

Coming closer to the end, this chapter walks the reader on the various aspects of building a mobile client that connects to the cloud using Azure Mobile Services. We see how to implement a mobile-enabled web application and Web API service, how to publish it and how to implement a matching Windows Phone application, fully featured with push notifications. It also guides us on configuring the mobile service with Active Directory for authentication. At the end we are shown how to build a Windows Store app to interact with our application.

Chapter 12: Preparing an Azure System for Production

The final chapter puts everything in place, explains how to setup different build configurations for different deployment environments and how to build and deliver deployment packages for Azure. At the very end we get a deployment checklist that may come in handy if ever we run into problems.

Conclusion

Overall, I enjoyed reading this book. It doesn’t cover all of Azure, but it does a very decent job in explaining how one can build a real-life application that works and handles most typical concerns, including support for mobile devices.

Unity, Part 10: Custom Build Strategies

Introduction

We’re getting there! This time, custom build strategies, or how you can tell Unity to build/act upon built objects in different ways.

The latest post in the series was on integration with MEF, the previous on web, before that on interfaces, even before I talked about conventions, values, extensions, Aspect-Oriented Programming, dependency injection and the first was an introduction.

Unity allows specifying custom build strategies. Depending on the stage to which they are applied, they can either build objects for us or do something upon newly built ones.

Performing Operations On Newly Built Objects

One example of the latter: suppose we wanted to implement support for ISupportInitialize (I repeat myself, I know). This is a marker interface that features two methods: BeginInit for signaling the start of the initialization process and EndInit for its end. We need a custom build strategy that knows when to call each of these methods. We add build strategies through extensions:

   1: public sealed class SupportInitializeContainerExtension : UnityContainerExtension

   2: {

   3:     protected override void Initialize()

   4:     {

   5:         var strategy = new SupportInitializeBuilderStrategy();

   6:         this.Context.Strategies.Add(strategy, UnityBuildStage.Creation);

   7:     }

   8: }

Notice how we add our build strategy to the Creation build stage. This tells Unity that the strategy’s lifecycle methods should be called before and after the object is created. It’s important to remember that only components registered with RegisterType will be intercepted, because those registered with RegisterInstance are, of course, already built.

Extensions are added to the Unity instance:

   1: unity.AddNewExtension<SupportInitializeContainerExtension>();

The build strategy itself inherits from BuilderStrategy, which in turn implements IBuilderStrategy; it’s implementation is straightforward:

   1: public sealed class SupportInitializeBuilderStrategy : BuilderStrategy

   2: {

   3:     public override void PreBuildUp(IBuilderContext context)

   4:     {

   5:         var init = context.Existing as ISupportInitialize;

   6:  

   7:         if (init != null)

   8:         {

   9:             init.BeginInit();

  10:         }

  11:  

  12:         base.PreBuildUp(context);

  13:     }

  14:  

  15:     public override void PostBuildUp(IBuilderContext context)

  16:     {

  17:         var init = context.Existing as ISupportInitialize;

  18:  

  19:         if (init != null)

  20:         {

  21:             init.EndInit();

  22:         }

  23:  

  24:         base.PostBuildUp(context);

  25:     }

  26: }

PreBuildUp and PostBuildUp are called in sequence just after the object is built (the Existing property). Other lifetime methods exist, which are called at different times, depending on which stage the builder was added to.

Overriding Object Creation

Another example would be intercepting object creation. For that we need another extension:

   1: public sealed class CustomBuildExtension : UnityContainerExtension

   2: {

   3:     public Func<Type, Type, String, MethodBase, IUnityContainer, Object> Constructor { get; set; }

   4:  

   5:     protected override void Initialize()

   6:     {

   7:         var strategy = new CustomBuilderStrategy(this);

   8:         this.Context.Strategies.Add(strategy, UnityBuildStage.PreCreation);

   9:     }

  10: }

The Constructor delegate property takes a number of parameters and returns an object instance. These parameters are:

  • First Type: the registered type, such as ILogger;
  • Second Type: the concrete type mapped, an ILogger implementation such as ConsoleLogger;
  • String: the registered name, such as “console”, or null;
  • MethodBase: the method (or property getter/setter) where the component resolution was requested, for context;
  • IUnityContainer: the current Unity instance;

We would register it as:

   1: var extension = new CustomBuildExtension();

   2: extension.Constructor = (from, to, name, method, u) =>

   3: {

   4:     //return something

   5: };

   6:  

   7: unity.AddExtension(extension);

The strategy in this case would be like this:

   1: public sealed class CustomBuilderStrategy : BuilderStrategy

   2: {

   3:     private readonly CustomBuildExtension extension;

   4:     

   5:     public CustomBuilderStrategy(CustomBuildExtension extension)

   6:     {

   7:         this.extension = extension;

   8:     }

   9:     

  10:     private IUnityContainer GetUnityFromBuildContext(IBuilderContext context)

  11:     {

  12:         var lifetime = context.Policies.Get<ILifetimePolicy>(NamedTypeBuildKey.Make<IUnityContainer>());

  13:         return lifetime.GetValue() as IUnityContainer;

  14:     }

  15:     

  16:     public override void PreBuildUp(IBuilderContext context)

  17:     {

  18:         var stackTrace = new StackTrace();

  19:         var frame = stackTrace.GetFrame(6);

  20:         var method = frame.GetMethod();

  21:         var fromType = context.OriginalBuildKey.Type;

  22:         var name = context.OriginalBuildKey.Name;

  23:         var toType = context.BuildKey.Type;

  24:         var unity = this.GetUnityFromBuildContext(context);

  25:     

  26:         context.Existing = this.extension.Constructor(fromType, toType, name, method, unity);

  27:         context.BuildComplete = true;

  28:     

  29:         var lifetimeManager = new ContainerControlledLifetimeManager();

  30:         lifetimeManager.SetValue(context.Existing);

  31:     

  32:         context.Lifetime.Add(lifetimeManager);

  33:     

  34:         base.PreBuildUp(context);

  35:     }

  36: }

Worth mentioning:

  • A StackTrace instance is used to walk back the stack until our custom method was called;
  • The from type, name and to type are obtained from the OriginalBuildKey and BuildKey;
  • The Unity instance is a bit more tricky to get, it comes from the current Policies;
  • Existing and BuildComplete are set so that the build process is terminated with this builder;
  • The Constructor delegate is invoked and should return a proper object inheriting (or implementing) from from type;
  • A ContainerControlledLifetimeManager (aka, singleton) is used to track the new object lifetime and added to Unity’s Lifetime collection, so that when Unity is disposed of, the lifetime manager also gets disposed.

And that’s it. This way, you can decide how your object is going to be built and even on which method is it being requested. Hope you find this useful! Winking smile

Lesser-Known NHibernate Features: Filtering an Unloaded Collection

Suppose you have an entity with a collection of other entities (one to many, many to many); this collection is normally represented by some property implementing IEnumerable<T>, or one some more specific interface.

If we want to query this collection, we normally have to load all of its items. For indexed collections, it is possible to use extra-lazy laziness, which means NHibernate will only load one item at a time, instead of all at once, but this might even be worse, because it would result in multiple SELECT statements.

NHibernate offers a nice mechanism to filter and order a collection without actually loading all of its items; it’s the CreateFilter method of the ISession, and we use it like this:

   1: //get an order

   2: var order = session.Query<Order>().First();

   3:  

   4: //all order details of this order where quantity is greater than one

   5: var detailsWithMoreThanOneItem = session.CreateFilter(order.Details, "WHERE Quantity > 1").List<OrderDetail>();

   6:  

   7: //all order details of this order sorted by their quantity in descending order

   8: var detailsSortedByQuantityInDescendingOrder = session.CreateFilter(o.Details, "ORDER BY Quantity DESC").List<OrderDetail>();

I even once wrote a helper method for querying collections with LINQ without actually loading them; its usage is:

   1: //all order details of this order where quantity is greater than one

   2: var detailsWithMoreThanOneItem = order.Details.Query().Where(d => d.Quantity > 1).ToList();

The Query extension method will check to see if the collection has already been loaded, in which case, it resorts to LINQ to Objects, otherwise, it generates a proper LINQ query. You can find the source code here.