.NET: Framework

I’m going to start putting together some posts related to the world of .Net (pronounced ‘dot net’). I’m a big fan of .Net and figured it could be useful.

For this post I wanted to target the .Net Framework. So lets get stuck in…

The .NET Framework was formally released in 2002 by Microsoft and is one of the most commonly used methods of Software Development, hopefully something you’re interested in? If not, stick around, check out some of my other posts and see what happens…

The .Net Framework implements the Common Language Infrastructure (CLI) which is an Open Specification developed by Microsoft, with Hewlett-Packard, Intel, and others and the specification was standardised by the International Organisation for Standardization (ISO) and the European Computer Manufacturers Association (ECMA) completing in 2003.
The .Net Framework includes a large Class Library called the Framework Class Library (FCL) and a runtime environment called the Common Language Runtime (CLR).
Applications can be developed using multiple programming languages including C# (pronounced ‘C Sharp’), Visual Basic.NET, and F# (pronounced ‘F Sharp’) with language interoperability. We get a large number of APIs from the framework we can use for example database access using ADO.Net and the Entity Framework, web development including apps and services with ASP.Net, desktop services with the Windows Communication Foundation (WCF), and User Interface Development with Windows Presentation Foundation (WPF). So we can do quite a variety of development through the .Net Framework and to avoid getting side tracked I won’t go into any more detail on the above usage paths in this post, they really deserve their own posts.

Before we could develop .Net Framework applications we primarily used the Component Object Model (COM), at least on Windows, to share code across languages and for cross application communication. Sounds ok right? Well not really, COM was complicated and fragile. So Microsoft quite kindly developed the .Net Framework and it quickly took the place of COM.

Ok so we know .Net is great and all but what is it exactly?
As touched on above it comes in two primary parts the CLR and the FCL.

The runtime environment (CLR) takes a fair bit of work away from us such as finding, loading, and managing .Net objects. It means we don’t really need to worry about memory management (unless we’re using unmanaged code), app hosting, thread coordination, type safety, garbage collection, exception handling, security checks, and other low-level details. By use of Just-In-Time compilation, the runtime converts our managed code (called the Common Intermediate Language (CIL) into machine instructions, called binary, understood by the computer.
As part of the CLR, we get something called the Common Type System (CTS) which is a standard that describes type definitions and programming constructs supported by the runtime. The goal here is to allow our applications to easily share information among themselves, even if those applications are written in different .Net languages.
One more step down we have the Common Language Specification (CLS) and this specification defines a subset of type and constructs. If you end up writing a library where the types are only CLS-compliant this library can be used across all .Net languages.
See the image below for a visual representation…

Common Language Runtime visual

Lets look at the FCL, it is the .Net Frameworks implementation of the standard libraries defined by the Common Language Infrastructure (CLI). The core part of the FCL is the Base Class Library (BCL) as the name suggests this core section contains only the base essentials such as:

  • Threading
  • Security
  • File Input/Output (I/O)
  • Base types; such as Object
  • Collections
  • and more

I’ll put a post up that is just the namespaces and a brief description.

The FCL on a wider scale includes everything and can be used to develop any type of software application from web to console (Xbox).

So that’s a very quick introduction to the .Net Framework, hopefully you found it interesting.

If you have any questions feel free to ask.

Don’t Repeat Yourself

This week lets take a look at a(nother) useful principle, the Don’t Repeat Yourself (or DRY) principle. The goal here is to get an idea of how the principle works and then aim to incorporate it into your day to day development activities. Remember to try to combine it with the other principles we’ve looked at, for example the Single-Responsibility Principle from the SOLID principles.

So where’d this one come from?

Introduced by Andrew Hunt and David Thomas in their 2000 book “The Pragmatic Programmer” they define DRY as

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

What we are basically aiming for is don’t say (following Uncles Bobs tell a story advise) or do the same thing twice. If you have some logic that performs a useful job, or even if its not that useful, don’t repeat that code. Combined with Single-Responsibility you could wrap that it up behind a class or method and have a single definition (“authoritative representation”).

I read a quote once that is quite good, “The only bug free code is no code” another is “Code that doesn’t exist is code you don’t have to debug” (can’t remember the original authors). Essentially what both of these statements are telling us is, write as little code as you can to get the job done. By following DRY we can shrink our code base by reducing repetition and therefore reduce the chances of bugs or introducing bugs through changing the same piece of code found in multiples places.

Another benefit we get from DRY is if you have a block of code duplicated throughout your code base and you need to make a change to that block not only do you have to go and update all blocks but there’s a chance a bug can be introduced through this change (at the end of the day we’re only human). Now if that code block was held in one place, meaning only one update was required we save time and reduce the chance of introducing bugs.

One example is say we needed to modify a piece of data using the following steps:

const int TEMP = 10;
double x = 30;
double y = 5;

x = x * TEMP;
x + y;
x / 10;

Now instead of duplicating this “important” bit of code we can wrap it in a suitably Named class or method and simply call that.

That’s it really, if you find yourself writing the same piece of code more than once consider if it may be worth extracting all instances of that block.